Subject: 5/5 Re: I-D ACTION:draft-danli-wrec-wcip-00.txt

From: Mike Dahlin <[email-masked]>
Date: Tue, 21 Nov 2000 21:08:25 -0600

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.