Dan Li wrote:
> I think I now fully understand your points. I agree that concept 1
> (Object Volume) is by far the most fundamental, while concept 2
> (atomic group update) is more of an optimization. It seems that we
> should need 5 or 6 bullet items to describe the various requirements
> on concept 1, and one bullet item concentrating on concept 2 because
> it's not as fancy. What do you think?
As I had it written originally, 1-4 were about "notification groups"
(the "second concept"), but as I re-read it, you're right -- perhaps
they would be better as a separate concept -- regardless of grouping,
we want notifications to be extensible. This gives 5 bullets about
concept 1, 2 about concept 2, and 2 more under the new concept of
"extensibility".
So, perhaps we could replace "6.2 Naming and Framing" with three
subsections. E.g., something like the following:
6.2 Synchronization groups
--------------------------
1) The protocol must enable definition of a "synchronization group" of
objects.
synchronization group -- a group of objects about which a client can
subscribe to receive notifications.
Synchronization groups represet the granularity of
synchronization. RUP servers must only send notifications about
resources in a synchronization group to RUP clients that have
requested notifications for that group.
// My old 5 + an attempt to make the definition more clear
2) The policy to group resources into synchronization groups is
outside the scope of RUP. Grouping may be determined by the content
provider, CDN operator, traffic analysis tools, or other means. RUP
is not required to provide dynamic negotiation between the RUP
server and RUP client over the composition of a resource group. In
other words, "targeted invalidation", in which a server only sends
an invalidation about object X to clients that have registered
callbacks on object X, is out of scope for the initial version of
RUP. This restriction is motivated by complexity and scalability
concerns about servers (and clients) having to negotiate and
maintain individual views of resource groups for all the RUP clients
(and servers) they speak to. It's anticipated that predefined
resource groups will fit well with the majority of the RUP
deployment cases (surrogates, mirror sites, and CDNs).
// My old 6
3) RUP must support "in band" and "out of band" means to describe the
composition of a synchronization group. Our of band assignment of an
object
to a synchronization means that assignment occurs outside
of RUP information exchange procedure, (e.g., in the object's HTTP
header.) In-band assignment would include a synchronization
group definition message in RUP. An out-of-band HTTP header based
approach specification is simple and makes it efficient to determine
to which group an object belongs, while in-band specification should
be supported so that RUP is self-contained. In particular, CDN
operators would prefer not having to change the origin web server
before anything can be put into a resource group, but rather
self-describe the composition within the group.
// My old 7
4) The protcols for describing synchronization group composition
should be efficient with respect to both network transmission and
client-matching logic for both in band and out of band
protocols. Network transmission should support descriptions that
grow less than linearly with the number of objects in a volume
(e.g., URI prefix or regular expression matching) but they may also
support listing of objects. For "out of band" protocols, they may
support allowing a header to indicate that the current object is
part of a particular synchronization group (rather than fully
specifying the membership of the synchronization group). In order to
service reads efficiently, it must be possible to implement matching
logic so that work to determine which synchronization group(s) a
cached object is a member of grows much more slowly than linear in
the number of synchronization groups. (For example, consider a
hypothetical RUP protocol where the membership of a synchronization
group is specified by a short list of URI prefixes. Such URI
prefixes can be organized into a tree so that given an object URI,
the enclosing URI prefix can be found in work logarithmic to the
number of URIs. Conversely, it may be more difficult to determine
which (if any) arbitrary regular expression matches a given URL, so
allowing synchronization groups to be defined by arbitrary regular
expressions may limit scalability of RUP clients.)
// My old 8
5) The protocol should allow RUP servers to be common with or disjoint
from data servers. Therefore, in addition to specifying the
collection of URIs that belong to a synchronization group, a in- or
out-of-band definition of a synchronization group must also specify
protocol and server information that indicate with whom to
communicate (e.g., "wcip://example.acm.org/channel7").
// My old 9
6.3 Notification groups
-----------------------
1) The protocol must enable atomic notification regarding an arbitrary
"notification group" of resources. For example, the protocol must be
able to invalidate a list of multiple URIs with one message.
// My old 1
2) The protocol must enable efficient notification regarding a
pre-specified group of resources (i.e., it must be possible to
define a group where a notification that applies to all members of a
group can be transmitted with network bandwidth that grows less than
linearly with the size of the group.) For example, the protocol might
implement this requirement by allowing a notification group to be
specified in different ways such as (1) by a list of URIs included
in the message, (2) by a regular expression or path prefix that
refers to a set of URIs, and/or (3) by a URI that itself refers to a
(possibly hierarchical) list of URIs.
// My old 2
6.4 Notification and extensibility
----------------------------------
1) As an extension mechanism, a RUP message may carry a set of options
for a notification group of resource. The set of options may be
empty. RUP must specify a generic option format and define the
content prefetch hint and content location update as options. No
option is mandatory. A RUP client can ignore any options it doesn't
recognize or doesn't want to support. If positive acknowledgement is
requested, the acknowledgement must indicate the options it has
carried out.
// My old 3
2) The protocol must define an extensible format for RUP messages
that is capable of carrying a variety of payloads. Possible
payloads include (1) cache invalidation, (2) content location
update, (3) content prefetch hints, (4) removal and addition of
resources to a resource group, (5) adjustments to cache consistency
parameters, etc. While the above payloads may share the same RUP
mechanism, it's not a requirement for the initial protocol to
address all of them simultaneously.
// My old 4
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:22:59 MST