Subject: [Seamoby] RE: Section 5.5 Modifications

From: "Gary Kenward" <[email-masked]>
Date: Tue, 6 Aug 2002 12:13:08 -0400

Madjid:

  Fine, replace "before" with "proactive". I still use the term "proactive"
because I never associated it with the triggers (and neither did the
original
wording in the draft). 

  To sum up, the whole purpose of CT is to attempt to prepare the
destination
AR *before* a handover occurs and the destination AR has to forward it's
first
packet to/from the roaming MN. Performing CT *during* or *after* a handover
has
been initiated, particularly after the MN's packets have begun arriving at
the
destination AR is a necessary capability, but the potential performance 
improvements are not as great.

Gary

> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
> Sent: July 22, 2002 11:37
> To: 'James Kempf'; Kenward, Gary [WDLN2:AN10:EXCH]; Nakhjiri
> Madjid-MNAKHJI1; [email-masked]
> Subject: RE: Section 5.5 Modifications
> 
> 
> Well, I am maybe not as good of a boy scout as some others
> but, I remember 3 weeks of debate, followed by a period
> of  2 months of silence and then a 90 minute discussion in London 
> (not to mention the 3$K trip expense :) ) 
> that lead to us not making reactive
> or proactive CT as a basis for the CT usefulness debate. 
> Lets not open that barrel of snakes (certainly bigger than 
> worms) again.
> 
> If you want to mention proactive a byproduct, or use case, 
> that is fine.
> But I think we should be careful about making a byproduct a 
> primary goal.
> 
> 
> Regards,
> 
> Madjid 
> 
> 
> -----Original Message-----
> From: James Kempf [mailto:[email-masked]]
> Sent: Friday, July 19, 2002 7:47 PM
> To: Gary Kenward; 'Nakhjiri Madjid-MNAKHJI1'; [email-masked]
> Subject: Section 5.5 Modifications
> 
> 
> Hi Gary,
> 
> >   I get the impression that either everyone has forgotten 
> about proactive
> > CT, or does
> > not care. Which is too bad, for the boy scouts are right on 
> when they say
> > "be prepared".
> >
> 
> Thanx for reminding me, being an old Boy Scout myself I should have
> remembered.
> :-)
> 
> How about if we modify the text I sent out as below? In 
> addition, I think we
> need an additional section, which I will post on a separate 
> thread, that
> describes the steps needed to standardize a feature context. 
> This text will
> include a requirement for update on feature contexts that are 
> not tightly
> synchronized with external events.
> 
>                 jak
> 
> ------------------------------------------------------------
> 
> 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 individual feature contexts will
> differ in
> their
> need for update.
> 
> 5.5.4 The base context transfer protocol MUST allow individual feature
> context
> specifications to define their own update procedures if required.
> 
>         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 general CT solution need not support it, 
> but it should
> not
>        provide a hinderance to those feature contexts that do.
> 
>        Feature contexts will differ in whether or not they 
> require update.
>        A feature context such as QoS parameters for the service level
> agreement
>        with a user may not involve dynamically changing 
> information, but it
> may
>        change during or after context transfer. Such feature 
> contexts may
> benefit
>        from allowing the context to change after the transfer 
> is completed.
> Other
>        feature contexts, such as header compression, may be tightly
> synchronized
>        with external events and changes on the old router need to be
> discarded
>        since the new router's state may already have been modified.
> 
> 
>

---

From: "Gary Kenward" <[email-masked]>
Date: Tue, 6 Aug 2002 12:13:08 -0400

Madjid:

Gary