Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement

From: "Gary Kenward" <[email-masked]>
Date: Mon, 15 Jul 2002 10:56:06 -0400

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:[email-masked]]
> Sent: July 14, 2002 18:52
> To: [email-masked]; [email-masked]
> Subject: Re: [Seamoby] Proposal on Sync/NoSync Requirement
> 
> 
> That sounds better.
> 
>             jak
> 
> ----- Original Message ----- 
> From: <[email-masked]>
> To: <[email-masked]>; <[email-masked]>
> 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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/seamoby
>

---

From: "James Kempf" <[email-masked]>
Date: Mon, 15 Jul 2002 18:12:27 -0700

Gary,

I'm fine with your proposed changes. Any further comments from the WG?

            jak

----- Original Message -----
From: "Gary Kenward" <[email-masked]>
To: "'James Kempf'" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Monday, July 15, 2002 7:56 AM
Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement

---

From: "James Kempf" <[email-masked]>
Date: Mon, 15 Jul 2002 18:12:27 -0700

Gary,

            jak

----- Original Message -----
From: "Gary Kenward" <[email-masked]>
To: "'James Kempf'" <[email-masked]>; <[email-masked]>;
<[email-masked]>

---

From: "James Kempf" <[email-masked]>
Date: Fri, 19 Jul 2002 06:04:26 -0700

Gary,

> 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.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

---

From: "James Kempf" <[email-masked]>
Date: Fri, 19 Jul 2002 06:04:26 -0700

Gary,

Comments?

                jak