Re: [Seamoby] Proposal on Sync/NoSync Requirement

["James Kempf" <[e-mail]>]

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







_______________________________________________
Seamoby mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/seamoby