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

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

3. I would suggest adding a separate subsection about reconnection in
   section 3. This would provide a place to talk about a bunch of the
   subtle issues all in one place: first connection, reconnection,
   incremental connection, using legacy headers while waiting for
   connection, ...

   Some additional features to optimize reconnection may be warranted.

(3.1)
First, I think it is worth stating precisely the per-object FSM:
(In writing this, I'm catching some bugs in my understanding at least;
I suspect other people might also benefit from explicitly including
this in the draft.) I would bet that at least some one in this
discussion will say "I don't think it works like you described" and
they might be right; either way, this would be an indication that it
is worth writing it down so we can argue about how it works in
concrete terms...

Each object has two parts to its state:
1) Synchronization established/lost for object --> are we guaranteed
to receive an invalidation if the current version of the object changes?

2) Current version cached/not cached --> a version of the object is
cached that may be current (no invalidations have been received for
it). If the synchronization is established, then it IS current;
otherwise, it may be, but cache control directives apply.

Notice that because of server-driven reconnection, we can be
synchronized for an object even if we don't currently cache that
object.
                                            Read
                     synch established     <---   synch established
       current version cached ---->  current not cached
      |           /|\         recv        |           /|\
                    |            |          inval       |            |
                    |  connect   |  current             |  connect   |
current
      |  lost      |  version #           |  lost      | version
                    |            |  recvd               |            | #
recvd
                   \|/           |           Read      \|/           |
                    sync not established   <-----  synch not established

      current version cached ------> current not cached
                              Recv
                                            inval

Action on READ:

  sync established
  current version cached:
       return data

  sync established
  current not cached:
       Request newest version from origin server
       Recv newest version from origin server
       state = Sync estab; current cached

  sync not established
  current version cached:
       if legacy headers allow read, then
          if (server supports targeted inval)
             send "register" to inval server
   return read data
       else
          set state "sync not estab; current not cached" and follow
   those rules for READ

  sync not established
  current not cached:
  Request newest version from origin server
  Recv newest version from origin server
  if(inval server supports targeted inval)
      send "register" to inval server
  set state "sync not established; current cached"

Action on CONNNECT LOST
   set "sync not established"

Action on CURRENT VERSION # RECVD
   set "sync established"

   Notice that this may be received either in response to explicit
client request to resynchronize or because server periodicaly sends
out current version numbers?

Action on INVAL RECVD
    current version = no current version
    POSSIBLE BUG/OPTIMIZATION: does inval hold current version number
    and therefore always allow you to go to "sync established, no
    current version"?

(3.2)
Second, as mentioned in previous message (main comment #2 in
notes.11.20.2000b.txt), the idea described for server-driven
resynchronization for multicast seems like it can be/should be
explicilty generalized:
(Most of these features are implicit in the current draft; all I'm
really suggesting here is to make them explicit.)

The following seem to be defined:
    server-driven resynchronization: servers periodically send out all
    of the current version numbers for all of the objects (currently
    defined for multicast sync/resync case)

    client-driven resynchronization: clients ask for the current
    version numbers of the objects they cache (currently defined for
    the unicast resync case).

But it is worth noting that server-driven/client-driven
resynchronization are extreme points in a continuum. In the
client-driven case, it is not necessary to re-establish
synchronization on everything at once (but it may be desirable to
establish synchronization on some subset of data you think you will
soon use).

Note that the same mechanisms/rules apply for resynchronization after a
reconnection and for establishing synchronization when a new object is
read. Also, the only difference between targeted service and
untargeted service is just one message: in either case, a client gets
synchronized when it receives a message from the server indicating the
current version number; the only difference is that in targeted
service, the client has to ask for such a message whereas in
untargeted service, such messages periodically appear. (Put another
way, revalidation messages have no semantic meaning -- they may be
lost, reordered, or spontaneously appear at any time; they are just a
hint that "now" might be a good time for the server to send
a current version number to a client.) Finally, this
framework cleanly separates mechanism from policy: e.g., on
resynchronization under targeted service, a client may choose to
register all cached objects, no cached objects (make them all "sync
not established"), or a subset of cached objects (e.g., do a "bulk
re-register" on index.html and all inlined images; then do a
background re-register of all other cached objects from that
channel). E.g., a client may establish a callback on an object the
first time it reads the object or the first time it revalidates the
object and the object didn't change~\cite{dilley}.

To support this, the protocol should explicitly state whether a client
may contact a server to resynchronize an object. This is implicit in
the "no-target" header. This section and section 5.2.2 should make
this rule explicit. (Or should there be a separate header field?)