5. Other points
5.1 I would suggest adding a separate subsection on legacy rules to
section 3. There is not a whole lot to say, but putting this set of
rules in one place would aid clarity, I think.
5.2 I would be inclined to call "application-layer multicast"
"hierarchy"
since more is going on than multicast -- the nodes near the leaves can
reply to registration requests (I think?)
5.3 We probably need to think through the delta-encoding under
multicast case
(I seem to remember some relatively complex rules about "base"
versions and so on; just need to make sure everything still makes
sense under multicast.)
5.4 Various broken sentences/grammer errors throughout. Once content
stabilizes, a thorough pass is needed.
Get rid of all contractions.
5.5 Section 2 needs to define "channel lifetime" (but see main comment
#1 in notes.11.20.2000b earlier message)
5.6 Section 2 and section 3.1
I think it is worth explicitly explaining that the protocol provides
consistency in two ways: a worst-case freshness guarantee and an
average-case delay between update and invalidate.
So, section 2 should define
common-case invalidation latency
average amount of time between an object update and when a
synchronized client caching that object finds out that the old
version is invalid. This time depends on network and
invalidation server topology, the number of clients, server
load, message losses, and other factors and is not a
guarantee.
And it should extend the "invalidation latency" definition to
explicitly describe the relationship between the two components: worst
case freshness guarantee and common case invalidation latency.
Then in Section 3.1, a paragraph between the second-to-last and last
paragraphs should explain these two pieces. And the last paragraph of
section 3.1 should point out that two extreme cases are supported by
the protocol: (1) set worst-case guarantee to "large" --> get fast
common-case updates but no worst case guarantees ('eventual
consistency') (2) batch invalidation messages with heartbeats --> get
worst case guarantees and common case = worst case.
5.7
Section 3.2.1 -- strike "so is better than UDP-based invalidation,
too"
5.8
Section 3.4 on "channel security" needs work. Starting off with "the
barn door is already open" is weak.
Suggested reorganization:
1. Start with a list of vulnerabilities/threats
2. Move the paragraph "to prevent intermediate nodes from
tampering..." up to the first few paragraphs -- this rule is true
regardless of which of the remaining options is chosen.
Add to this paragraph "Note that the origin server can be an HTTPs
server or an HTTP server." after the first sentence.
3. Move "weak ok" argument under option #1
4. The paragraph
This is when the invalidation server requires strong security for
the channel. The invalidation clients have to comply. For unicast,
the channel can simply be a SSL connection as in HTTPS.
Is really a 4th case (it is not "public-key-based strong security with
mandatory verification").
5.9 In section 4.3 "form channels" the statement "But with more
objects per channel, there will be more cost for each client's
targeted service state" is false. (There will be more state per
channel, but the total amount of state across channels will be the
same.)
5.10 steps 4 and 5 in section 5, section 5.2.4 may need to be
revisited depending on results of the "channel lifetime" discussion
5.11 Section 5 "Symbols already defined in ... are not repeated here"
Perhaps these should be listed. Then, a reader that hits an
unrecognized symbol can check whether it is defined elsewhere (or
whether the reader just missed it here) before digging out the other
doc. (Also, this allows us to make sure that all terms are defined by
looking at just this document and its "interface" to the other docs.)
5.12 In section 5.1, should a channel type for unreliable multicast be
specified?
"channel information" is defined in 5.1 and "channel-info" is
defined in 5.2.2. This is confusing.
At the same "level" as the channel type, I would have expected the
"no-target/target" flag to appear, since the network protocol and
the target/no-target directives both describe the language to speak
between the client and server
5.13 In section 5.2.2
If you like the optimizations I describe for unreliable multicast
case, then seqno needs to be generalized to allow for a range
5.14. in section 5.1
Last sentence "via HTTPS" --> "via HTTP or HTTPS"
5.15. section 5.2 assumes persistent connection unicast; what about
other cases?
5.16 last paragraph section 5.2
"invalidation server MAY close" --> "invalidation server or
invalidation client MAY close"
5.17 section 5.2.4 first paragraph
How does an invalidation server (particularly an intermediate
server in a hierarchy) know what value is "smaller than
the lowest object freshness guarantee" given that it may not know
the freshness guarantee of all objects in a channel (it may only
know the FG for the objects it has seen.)
5.18 Section 5.2
It seems expensive to send a "register" with a list of objects to
resynchronize and then to be redirected to a different
invalidation server (and resend the list).
Perhaps the messages "establish channel" and "register
[objectlist]" should be split into two messages. There is no
problem with the semantics since registration can be
incremental. The question is one of performance: an extra round
trip when no redirect v. extra work when there is a redirect.
I believe the conservative thing to do is to split the messages
-- a fixed cost (a round trip) v. a potentially unbounded cost
(sending a long list of stuff twice).
Another option would be to add a hint in the Invalidated-By
header saying "on your initial registration, don't synchronize
more than N objects"
Another option is to say that "on the first request to a channel,
we don't know if we will be redirected, but we also don't have
anything to synchronize --> the right thing just happens; on
later requests to a channel, we have already been redirected and
we will will connect to the redirected target (is this how that
works?) --> the right thing just happens."
5.19 Section 5.2
"If there is targeted service, only objects specified in the targeted
service (in the registration request body) are returned in the
registration response body. Otherwise, all objects covered by the
invalidation channel are returned in the response body."
Yikes! The "all objects" in the second sentence could be huge!
I do not believe this is consistent with what is described in 3.2.3
(IP multicast) where, I think, the assumption is
if no targeted service, clients don't "register"
instead, servers periodically bring everyone in the
untargeted channel up to date
Even if registration is allowed under untargeted service (e.g., as
an optimization to let a client connect sooner), there is
no semantic need to send everything. The server can still just send
the current version numbers for the objects that a client cares
about.
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:21:29 MST