RE: [Seamoby] CT Requirements Comments from IESG

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

Madjid:

  Two comments:

    1. As I responded to James, using CT in preparation of possible
handovers *is*
       the main opportunity to ensure seamless. Trying to catch up to a
handover,
       once it has begun, is very difficult, and likely to fail in many
cases.

    2. What does "too early mean"? Just as there is no deterministic way to
predict the 
       direction of a mobile, and thus which AR the MN handsover to, there
is no deterministic
       way to predict when this will happen. So, while the network/MN may
know that the
       MN has the potential to handover to, say, 3 or 4 ARs, and can prepare
for it,
       there is no way to pin down the epoch.

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

Gary

-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:[e-mail]]
Sent: July 18, 2002 17:17
To: Kenward, Gary [WDLN2:AN10:EXCH]; Nakhjiri Madjid-MNAKHJI1; 'Charles E.
Perkins'
Cc: [e-mail]
Subject: RE: [Seamoby] CT Requirements Comments from IESG


 
-----Original Message-----
From: Gary Kenward [mailto:[e-mail]]
Sent: Thursday, July 18, 2002 9:52 AM
To: 'Nakhjiri Madjid-MNAKHJI1'; 'Charles E. Perkins'
Cc: [e-mail]
Subject: RE: [Seamoby] CT Requirements Comments from IESG


Define "done"? 
 
Madjid>> Exactly my point, if you keep sending updates while you're
sending other context, you are never done.
 
Seriously, if CT is performed during or after a handover (reactively)
then, yes, there's not much more that can be done. If the context at 
the destination is out of synch with changes in the source context,
there is an increased risk that the seamlessness of the handover will
be degraded.
 
Madjid>> Yes, assuming you mean L3 handover,
and this is the most critical use of CT: optimization
of handovers. I can't have CT add to feature disruption by getting
into an endless cycle of updates.
 
However, if CT is performed before a handover begins (proactively),
and changes occur at the source AR, then it would seem reasonable to
attempt updates. There is a presumption here that there is something
to be gained in handover performance by performing CT in advance of
an actual handover. It could turn out that CT (and the subsequent installion
of context at the destination AR) is so fast, that leaving the transfer 
of context until a handover occurs (i.e. no proactive, only reactive) is
a sufficient, and simpler solution. We really won't know whether this
is the case until the wg starts looking at CT solutions. 
 
Madjid>>sure, but this is not a time-critical CT and CT needs to send
updates because
it started too early on a dynamic context.
 
 
 
  
Cheers,
Gary
-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:[e-mail]]
Sent: July 17, 2002 19:25
To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Charles E. Perkins'
Cc: [e-mail]
Subject: RE: [Seamoby] CT Requirements Comments from IESG


Well, not trying to regurgitate (as you said)
but we never agreed on timing and reliability requirements and maybe
that was ok, because they depend on the scenario and protocols.
So why talk about sending updates after CT is done?
 
 
Madjid
-----Original Message-----
From: Gary Kenward [mailto:[e-mail]]
Sent: Friday, July 12, 2002 2:35 PM
To: 'Charles E. Perkins'
Cc: [e-mail]
Subject: RE: [Seamoby] CT Requirements Comments from IESG


I agree Charlie. However, we have to fix the issue with 
the requirements. Are you suggesting that we relax the 
requirement? By how much - clearly, some updates are required 
(e.g. CT really should try and update when flows come and go). 
Gary 
> -----Original Message----- 
> From: Charles E. Perkins [mailto:[e-mail]] 
> Sent: July 12, 2002 12:15 
> To: Kenward, Gary [WDLN2:AN10:EXCH] 
> Cc: [e-mail] 
> Subject: Re: [Seamoby] CT Requirements Comments from IESG 
> 
> 
> 
> 
> Hello folks, 
> 
> I think we ought to try to get context transfers 
> working correctly without initially worrying about 
> this synchronization problem. 
> 
> In the instances I am familiar with, it is not 
> required.  The most stringent case seems to be 
> ROHC, and even for that it is not necessary. 
> 
> We can solve the most urgent problems without having 
> to deal with any additional context synchronization. 
> When the old AR sends it, and the new AR gets it, 
> we should consider the transfer done.  In those 
> cases where reliability is at issue, the old AR 
> can retransmit when ACK is not received.  In many 
> cases, retransmission of context even once won't 
> be useful. 
> 
> Regards, 
> Charlie P. 
> 
> 
> 
> > Gary Kenward wrote: 
> > 
> > James: 
> > 
> >   Yes, we need to fix it, and I think it is doable. 
> > Thanks to Dirk for highlighting the real problem here 
> > (I think historically, the integrity requirement came out 
> > of the reliability section, and somehow, got lumped with 
> > synchronization and updates). 
> > 
> >   I think the requirements need a bit of rewording, and 
> > the paragraph should fall out from this. I do believe 
> > however, that making the synchronization of context between 
> > old and new AR a MUST requirement would be too extreme, and 
> > result in a brittle solution. CT should certainly do it's best to 
> > provide synchronization, but as was discussed in a recent 
> > exchange, it would be impossible to guarantee synchronization 
> > at any instant. 
> > 
> >   Any ideas/comments from the wg? 
> > 
> > Gary 
> > 
> > > -----Original Message----- 
> > > From: James Kempf [mailto:[e-mail]] 
> > > Sent: July 11, 2002 18:32 
> > > To: Kenward, Gary [WDLN2:AN10:EXCH]; [e-mail]; 
> > > [e-mail] 
> > > Subject: Re: [Seamoby] CT Requirements Comments from IESG 
> > > 
> > > 
> > > Gary/Dirk, 
> > > 
> > > I think you may be on to something here. I think this might 
> > > be what the IESG was talking about it the first point, namely the 
> > > lack of discussion of dynamic changes in the context. 
> > > 
> > > Is there some way we could cook this idea down into a 
> > > paragraph that we could insert for this requirement? 
> > > 
> > >             jak 
> > > 
> > > ----- Original Message ----- 
> > > From: "Gary Kenward" <[e-mail]> 
> > > To: <[e-mail]>; <[e-mail]>; 
> > > <[e-mail]> 
> > > Sent: Thursday, July 11, 2002 1:56 PM 
> > > Subject: RE: [Seamoby] CT Requirements Comments from IESG 
> > > 
> > > 
> > > > Dirk: 
> > > > 
> > > >   A valid point. There is a certain atomic level of 
> > > granularity which has to 
> > > > be 
> > > > dealt with - that is, there's no protocol in the world that 
> > > can synchronize 
> > > > changes in 
> > > > information that occur at the source while the information 
> > > is "in-flight" or 
> > > > being 
> > > > received at the destination. If changes in context while 
> > > the context is 
> > > > being transferred 
> > > > make a different to the successful performance of CT, then 
> > > there is no hope. 
> > > > 
> > > >   The problem is most significant for state context 
> > > transfer. E.g. counters 
> > > > will continue 
> > > > to count while CT is moving the context to the destination. 
> > > Either these 
> > > > changes have no 
> > > > significant impact upon the forwarding service provided at 
> > > the new AR (e.g. 
> > > > it may not 
> > > > matter that a policing meter misses a few packet counts), 
> > > or a different 
> > > > mechanism 
> > > > has to be defined for re-establishing the state context. 
> > > > 
> > > >   The handover is real and unavoidable. Mitigating the 
> > > disruption to the 
> > > > service at the new 
> > > > AR is the challenge. It would be nice if the disruption 
> was nil, but 
> > > > unlikely. 
> > > > 
> > > > Gary 
> > > > 
> > > > -----Original Message----- 
> > > > From: [e-mail] [mailto:[e-mail]] 
> > > > Sent: July 11, 2002 16:30 
> > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; [e-mail]; 
> > > > [e-mail] 
> > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG 
> > > > 
> > > > 
> > > > Hi all, 
> > > > 
> > > > jumping in as somebody who has been an observer so far, 
> > > struggling with the 
> > > > current discussion on 
> > > > 'integrity'. 
> > > > 
> > > > When I look at the current wording, i.e., 
> > > > "5.5.2 A context update MUST preserve the integrity, and 
> > > thus the meaning, 
> > > > of the context 
> > > > at each 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.", 
> > > > 
> > > > and compare this to the plain integrity of the actually 
> > > transmitted data 
> > > > (i.e., its bits and therefore its semantics) 
> > > > that has been brought to the table as a replacement now, 
> > > I'm quite confident 
> > > > that this is not what the requirement 
> > > > is talking about. 
> > > > 
> > > > If we remove the word 'meaning' (which is very vague 
> and free for 
> > > > interpretation for me as well), it is still the word 
> > > > 'integrity' left, which is more than plain integrity of the 
> > > transmitted 
> > > > data, in particular if we look at the following sentences 
> > > > in the requirement, which state what kind of integrity is 
> > > meant (which 
> > > > probably also builds the bridge to the vague 
> > > > term 'meaning'), namely that the integrity of a context 
> > > must be preserved in 
> > > > the sense that a received context at new 
> > > > AR at some point t must be the same as the context at old 
> > > AR at the same 
> > > > time t. This is by far more than plain data 
> > > > integrity of the transmitted data. Even if your data has 
> > > been transmitted 
> > > > correctly, the context might be stale (and therefore 
> > > > its integrity is lost) because it had changed at old AR in 
> > > the meanwhile. 
> > > > The action to be taken is also given in the text, 
> > > > namely the change of context has to be replicated to the 
> > > new AR. As you can 
> > > > (hopefully) see this is by far more than 
> > > > preserving the 'meaning' of each bit. It mandates that 
> > > changes in the bit 
> > > > values at one end are reflected at the other 
> > > > end, i.e., it talks about distributed data integrity in my 
> > > interpretation of 
> > > > the requirement text. 
> > > > 
> > > > Hence, the actual concern might have been (just guessing) 
> > > whether or not it 
> > > > is the task of the CT protocol to 
> > > > preserve the abovementioned integrity. Maybe, the IESG 
> > > wants to see this 
> > > > functionality left to the replication logic that resides 
> > > > within each AR. Or on the contrary, they do not see this 
> > > important topic 
> > > > covered appropriately. 
> > > > 
> > > > Regards, 
> > > > 
> > > > 
> > > > Dirk 
> > > > 
> > > > -----Original Message----- 
> > > > From: ext Gary Kenward [mailto:[e-mail]] 
> > > > Sent: Thursday, July 11, 2002 3:48 PM 
> > > > To: 'James Kempf'; [e-mail] 
> > > > Subject: RE: [Seamoby] CT Requirements Comments from IESG 
> > > > 
> > > > 
> > > > 
> > > > You call it fidelity, I call it data integrity. 
> > > > I've seen "data integrity" used in publications 
> > > > (no, I cannot quote references). 
> > > > 
> > > > What we need is a term that everyone, including the 
> > > > IESG, can agree upon. 
> > > > 
> > > > > -----Original Message----- 
> > > > > From: James Kempf [ mailto:[e-mail] 
> > > > <mailto:[e-mail]> ] 
> > > > > Sent: July 11, 2002 12:22 
> > > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; [e-mail] 
> > > > > Subject: Re: [Seamoby] CT Requirements Comments from IESG 
> > > > > 
> > > > > 
> > > > > > Perhaps the actual answer is to state exactly what 
> was intended 
> > > > > > originally: that the bit order and bit values have to 
> > > arrive exactly 
> > > > > > as they were transmitted. 
> > > > > > 
> > > > > 
> > > > > So this requirement is talking about transmission fidelity? I 
> > > > > sure would not have guessed that from reading it. I thought it 
> > > > > intended to talk about usability. 
> > > > > 
> > > > > I would suggest that the wording you have above is really a 
> > > > > lot more precise that what is currently in the spec. 
> > > > > 
> > > > > Any other comments? Could we substitute Gary's wording above 
> > > > > for "meaning" in the current requirement. 
> > > > > 
> > > > >             jak 
> > > > > 
> > > > > 
> > > > 
> > > > 
> > > 
> > > 
>