RE: [Seamoby] Proposal on Sync/NoSync Requirement

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

Madjid:

  I would like to respond to your comments with a general comment, which
hopefully covers much
of the issue. Correct me if this is not the case.

  The fundamental concern here seems to be over the scenario where the
context changes while a 
CT is already in progress. It does not seem to me to be a difficult task to
formulate a requirement
that states that CT will update, but at best, the granularity of the
synchronization will be greater
then the duration of a CT (lots of word smithing required, perhaps, but
doable). As far as I can
discern, the only detrimental effect of sending context updates to receiving
ARs is the protocol overhead.

A receiving AR may always decide that it does not need to use a context
update. It would probably make
this decision when, for example, it was receiving a handover, and had
installed context in preparation for
the arriving flows. In other words, the disruption of attempting to update
the installed context would 
be greater then the disruption of not having the latest context.

Now, dynamic, or state related context updates are a real problem. There is
a big issue as to when to
perform state updates, how often, etc. For example, if the dynamic context
is a packet counter, you
obviously do not want to be updating that context every time it changes. In
our work, we came to
the conclusion that while it was worthwile updated configuration context
when it happened, updating
dynamic context (e.g. state context) was not pratical, and indeed,
transferring of state context only
made sense to attempt just before the receiving AR needed the context.
Again, the assumption here
is that transferring configuration context ahead of time (e.g. ahead of an
actual handover), improves
seamlessness. There seems to be some evidence that it can.

As I see it, this whole discussion is around, as you put it, the
"NON-requirement" of ensuring that the
CT solution is not driven to meet extreme synchronization goals. We could
take this approach to many
of the requirements - e.g. if I say CT has to be fast, does that mean
pico-second transfer times? Clearly
it doesn't, but we do not have a requirement that says "CT should be fast,
but not too fast" (Note: the
actual requirement doesn't use the word fast - this is simply a counter
example). 

Cheers,
Gary
-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:[e-mail]]
Sent: July 18, 2002 17:54
To: Kenward, Gary [WDLN2:AN10:EXCH]; Nakhjiri Madjid-MNAKHJI1; 'James
Kempf'; [e-mail]; [e-mail]
Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement


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