RE: [Seamoby] Proposal on Sync/NoSync Requirement

["Gary Kenward" <[e-mail]>]

James:

 You have completely ignored "proactive CT", which for me, and I 
believe others, is the primary value of CT. If you deliver the context
to a receiving AR in the believe that it is a potential candidate for
handover,
and the context at the sending AR changes then an update seems like a
necessary
thing to do. At the very least, the context of newly created flows, or flows

being destroyed, should be conveyed. This could be part of the flow set up
semantics, but it seems wrong to insert CT into flow setup.

 The analogy for proactive CT here is soft handover: seamlessness at the IP
layer is analogous to soft handover at the link layer. 

 Finally, while I still would like to see CT progress, reducing the value of
CT by simplifying the requirements simply to get IESG approval, does not
seem
to me to be an appropriate approach. Proactive CT (now referred to as "CT
before
handover", *sigh*), is 90% of CTs value, to me, and I hope others concur.

Gary

> -----Original Message-----
> From: James Kempf [mailto:[e-mail]]
> Sent: July 19, 2002 09:04
> To: Kenward, Gary [WDLN2:AN10:EXCH]; John Loughney; [e-mail]
> Subject: Re: [Seamoby] Proposal on Sync/NoSync Requirement
> 
> 
> Gary,
> 
> > Proposed:
> >
> > 5.5 Context Update and Synchronization
> >
> > 5.5.1 The context transfer protocol MUST be capable of 
> supporting the
> >       updates to context information when it changes.
> >
> > 5.5.2 Context updates SHOULD complete before the context is 
> needed at
> >       the receiving AR.
> >
> >    The context at the AR actually supporting an MN's traffic will
> >    change with time. For example, the MN may initiate new 
> microflow(s),
> >    or discontinue existing microflows. Any change of context at the
> >    supporting AR must be replicated at those ARs that have already
> >    received context for that MN.
> >
> >    However, context changes are often driven by events 
> external to the
> >    sending AR, and will thus be asynchronous to any on-going context
> >    updates. Given that context transfers will take a finite 
> amount of
> >    time to complete, it is possible that a change in 
> context cannot be
> >    conveyed in time to the destination AR to avoid any 
> impact on a possible
> >    handover. The objective of the context transfer design 
> must be to make
> >    the likelihood of this delay, and its magnitude, as low 
> as possible.
> >
> >
> > This is not perfect: the desire to avoid a requirement for 
> an extreme degree
> > of synchronization is only implied by the soft "SHOULD" in 5.5.2.
> >
> 
> I still don't think this is sufficiently crisp. In addition, 
> after reviewing the
> email from the last couple weeks on this, I've seen good
> arguments why the CT protocol itself doesn't need to provide 
> update after
> the context has left the router.
> 
> We seem to be going through a bit of route flapping on this 
> one. Let me slip
> into solution space for just a moment (we'll be out again 
> quickly, never fear).
> The way I see the base CT protocol, it is the following things:
> 
>         1) A container format in which feature context blobs 
> get shipped. The
> container includes an identifier for the feature context, but 
> not much more.
> 
>     2) A procedure for standardizing blob formats. This will 
> require IETF
> standards action, plus IANA specification of type identifier.
> 
> So in order to use the CT protocol, a particular application 
> would have to
> define the following in a standards track specification:
> 
>     1) The detals of the blob layout and the IANA type code,
> 
>      2)  The transport for the CT container + blob,
> 
>      3) The synchronization requirements (if any) with 
> handover events.
> 
> For some feature contexts, there may be no synchronization 
> requirements. For
> others, there will be.
> 
> Popping out of solution space (phew, that was a little 
> tight!) , I see the
> following requirements supporting this situation:
> 
> 5.5 Context Update and Synchronization
> 
> 5.5.1 The base context transfer protocol SHOULD NOT provide 
> direct support for
> synchronization with outside events, since synchronization is 
> not a requirement
> for all
> or even most feature contexts.
> 
> 5.5.2 The base context transfer protocol MUST allow 
> individual feature context
> specifications to define their own synchronization with 
> external events.
> 
> 5.5.3 The base context transfer protocol SHOULD NOT provide 
> support for updating
> context after it is transfered, since context transfer is an 
> optimization, and
> updates would
> compromise the timeliness of the transfer. Changes in context 
> at the source are
> discarded
> after transfer has been initiated.
> 
>         Most feature contexts will not require 
> synchronization, however there
>         are a few that may. Header compression, for example, 
> may require that
>         the header compressor on the old access router cease 
> and the compressor
>         on the new router start in synchrony with hand over 
> of routing to the
>         new router; otherwise, the compressor on the new 
> router will not be
>        properly synchronized. Since most contexts don't need 
> synchronization
> support,
>         the CT solution need not support it, but it should 
> not provide a
>         hinderance to those feature contexts that do. Any 
> changes in the source
> router
>         that would cause changes in the context are discarded 
> after the context
> has
>         been transferred.
> 
> Comments?
> 
>                 jak
> 
> 
> 
> 
> 
> 
>