RE: [Seamoby] Proposal on Sync/NoSync Requirement

[Nakhjiri Madjid-MNAKHJI1 <[e-mail]>]

Gary,
Thanks for your reply. We are getting there. Please see comments below
 
BR,
 
Madjid
 
<snip> 
 > 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. 

Madjid>> Ok, as I recall the context transfer deals with a microflow

as a unit. The discussion of arrival and departure of    microflows is

relevant if you are aggregating multiple microflows, so maybe this

should be added to the section that talks about aggregation, otherwise

I think it is hard to avoid the interpretation I made (dynamic feature
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.  

Madjid>> glad to hear that. 

> 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  "Addition: 

by careful consideration of the rate by which context will change over time
. 

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

 Madjid>> Can't tell if you can put a NON-requirement to a requirement
document :)
but if you think it provides clarity, then fine. I added a little bit more
guidance at the end,
up to you whether you want to use it.  


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.  

Madjid>> "Context transfer must not add to the length of the disruption of
the feature, for 

which it is transfering states for, otherwise the use of context transfer

defeats its purpose"

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

Madjid>> well I didn't say "many". If the change of context is resulted

from an outside event by an outside trigger, the same information

may be sent to the new AR to update the context there instead. 

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. 

 Yes, I think you covered it yourself in your new formulation.

 
>    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