RE: [Seamoby] Proposal on Sync/NoSync Requirement

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

Madjid:
   
  Comments included:

> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:[e-mail]]
> Sent: July 17, 2002 20:12
> To: Kenward, Gary [WDLN2:AN10:EXCH]; 'James Kempf';
> [e-mail]; [e-mail]
> Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement
> 
> 
> Gary,
> 
> thanks for the suggestions, please see my comments below.
> 
> Madjid
> 
> 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.  
> 
>  Madjid>> Ok, this takes care of the dynamic context, however, we 

Actually, the real concern I have is not for dynamic context as it is
for changes in the makeup of the traffic for the MN - i.e. the arrival
and departure of microflows. This would change the configuration (aka 
static) context.

> need to be clarify that we are not requiring the oldAR sends updates
> to context features it has already transmitted while it is 
> transmitting
> context for other features, otherwise CT might never end.

I absolutely agree with you.

> Since, some folks have brought that up, I want to make sure that we
>  are not reading that in the requirement. Updates initiated by oldAR
> should only be based on outside triggers such as new flow, 
> flow terminations
> or messages from central entities...

There seems to be a concern that CT will not be able to guarantee perfect 
synchronization of the configuration and state of both ARs. My response to
this concern is, of course not, CT was never intended to do such a think.
This is not distributed computing, it is handover optimization.

Perhaps a new requirement would help clarify this, something like:

5.5.x Context transfer SHALL NOT attempt to guarantee perfect
synchronization
of context. The purpose of CT is to improve handover as best as it can.
Given
the complexity and overheads needed to synchronize distributed state
machines,
it is expected that occasionally, the context of the source and destination
AR will not agree. The CT solution must minimize the likelihood of this
happening.

5.5.x+1 Context transfer WILL NOT attempt to mitigate the effects of stale
context
        at the receiving AR. 


To me, this all seems like responding to "what if" scenarios, which if we
got
to far into this mode, could cause the number of requirements to explode. 
However, perhaps this is one distinction we should emphasize.

> 
> 5.5.2 Context updates SHOULD complete before the context is needed at 
>       the receiving AR. 
> 
> Madjid>> How do we know when the context is needed at the 
> receiving AR? 
> I find this more like a design guidance than a requirement. 

Well, a requirement is a design guide. The wg has debated this extensively,
Madjid, with, if I recall, no better resolution then the current wording.
If you have a recommendation for wording of a requirement that would
identify
when CT should be complete, please submit it.

> The following
> text
> can with some exceptions added to the explanation of 5.5.2.
> 
>    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. 
> Madjid>> the above is good.
> 
> Any change of context at the 
>    supporting AR must be replicated at those ARs that have already 
>    received context for that MN.
> Madjid>> MUSt is too strong. 5.5.1 is SHOULD, so should this one be
> (sorry for too many shoulds :)) There are ways to avoid having to do
> this through CT. 

Hmmm. Could you expand on the "many ways"? I am curious. 

As for MUST versus SHOULD: I think there is an issue here with
interpretation.
My interpretation is that CT MUST ATTEMPT to convey context changes at the
ARs.
That is, CT must provide the mechanisms to transfer context changes to all
ARs
that received the context originally. I agree that it is too extreme to
state
that the changes MUST make it to all ARs. Perhaps some rewording is needed.

>  
>    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. 
> 
> Madjid>> The above is good.
> 
> 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----- 

Thanks for the response; very useful input.

Gary