RE: [Seamoby] Proposal on Sync/NoSync Requirement

I don't think this requirement really resolves much of the issue
that has been under discussion, namely the level of synchronization
that is to be possible using CT.

CT for updates (as a result of new flows, or flows being discontinued)
is, I think, pretty straightforward. CT for state maintenance where the
state may change while a transfer is in progress is a much harder problem.

It matters not whether we say that CT solves this latter problem, or
provides
the support mechanisms, the demands that this would impose on the protocol
are extreme.

We need a requirement that clearly identifies what is meant by CT
synchronization:

Currently:

5.5 Context Update and Synchronization

5.5.1 The context transfer protocol MUST be capable of updating 
      context information when it changes.

5.5.2 A context update MUST preserve the integrity, and thus the
      meaning, of the context at each 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.

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. 

Regards,
Gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: July 14, 2002 18:52
> To: john.loughney@nokia.com; seamoby@ietf.org
> Subject: Re: [Seamoby] Proposal on Sync/NoSync Requirement
> 
> 
> That sounds better.
> 
>             jak
> 
> ----- Original Message ----- 
> From: <john.loughney@nokia.com>
> To: <kempf@docomolabs-usa.com>; <seamoby@ietf.org>
> Sent: Sunday, July 14, 2002 3:01 PM
> Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement
> 
> 
> > Hi James,
> > 
> > > "Out of scope" is typically WG charter language. I know the 
> > > SHOULD/SHOULD NOT sounds a bit funny, but I think we need to
> > > express this in a way that is more requirements language.
> > 
> > Then how about changing:
> > 
> >       ... the CT solution need
> >       not support it, but it should not provide a 
> hinderance to those feature contexts
> >       that do.
> > 
> > to:
> >       ... the CT solution is not requireed to directly 
> support synchronization, but
> >       may support simple methods for the synchronization 
> context for feature contexts
> >       that do.
> > 
> > John
> > 
> 
> 
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
> 