Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be , RE: Issue #4)

From: "Gary Kenward" <[email-masked]>
Date: Wed, 11 Jul 2001 16:27:17 -0400

James:

Err, no. That's not what I was agreeing to. 
Once again, proactive ct should be driven by the initiation
event, not the deadline event. It is preferable that context
be installed before the traffic arrives at the newAR, but it's
not a MUST requirement, and it certainly does not dictate that
ho and ct protocols must be synchronous.

And I see no reason for requiring handover signalling to complete
before ct (MIP may require it, but that's would be a potential 
MIP weakness, were it true). Even if this is true, it applies only
to reactive ct, and contradicts the purpose of proactive ct.

You seem to be implying that there is some dire consequence to be
realized if a ct happens but an ho doesn't. At best, the new AR
will be holding onto useless context. At worse, the new AR may
reserve resources that could be used elsewhere. Either situation 
seems resolvable with some sort of "life timer" and garbage 
collection. It does not imply that the two protocols be 
synchronous.

I'm missing the critical state relationship between ct and ho
that you are alluding to.

Gary

> -----Original Message-----
> From: James Kempf [mailto:[email-masked]]
> Sent: Wednesday, July 11, 2001 4:15 PM
> To: [email-masked]; [email-masked]; Kenward, Gary
> [WDLN2:AN10:EXCH]
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - 
> comments) (SHOULD
> be , RE: Issue #4)
> 
> 
> Right, well, then at least for this particular solution we 
> seem to agree there 
> is a need for a total ordering on handoff signaling and CT. 
> Namely, that
> handoff signaling must happen before CT. Not to rule out 
> there might be other 
> solutions where no ordering occurs.
> 
> Given this, it seems like the implementation consequences of 
> separating
> CT and handover signalling are the following. If nAR doesn't 
> know first that a 
> handover is going to happen and a CT packet arrives first, it must set
> a timer and wait until the handover signaling arrives. If the handover
> signaling doesn't arrive until the timer pops, nAR discards the CT.
> If it does, nAR completes the handover by replying back to oAR and
> installing CT. Then  awaits the arrival of the MN on the new L2.
> 
> Does this make sense?
> 
> 		jak
> 
> >From: "Gary Kenward" <[email-masked]>
> >To: "'James Kempf'" <[email-masked]>, [email-masked]
> >Cc: [email-masked], [email-masked], 
> [email-masked]
> >Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - 
> comments) (SHOULD be ,  
> RE: Issue #4)
> >Date: Wed, 11 Jul 2001 15:17:52 -0400
> >
> >James:
> >
> > Sure, but this presumes a specific handover solution.
> >
> >Gary
> >
> >> -----Original Message-----
> >> From: James Kempf [mailto:[email-masked]]
> >> Sent: Wednesday, July 11, 2001 3:15 PM
> >> To: [email-masked]; Kenward, Gary [WDLN2:AN10:EXCH]
> >> Cc: [email-masked]; [email-masked];
> >> [email-masked]
> >> Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - 
> >> comments) (SHOULD
> >> be , RE: Issue #4)
> >> 
> >> 
> >> Gary,
> >> 
> >> Seems like the arrival of the first packet, if it is being 
> >> tunneled from
> >> oAR, is predicated on the handover signalling being 
> completed between
> >> oAR and nAR, correct?
> >> 
> >> 		jak
> >> 		
> >> >Delivered-To: [email-masked]
> >> >From: "Gary Kenward" <[email-masked]>
> >> >To: "'Pat Calhoun'" <[email-masked]>
> >> >Cc: "'Nakhjiri Madjid-MNAKHJI1'" <[email-masked]>, 
> >> "[email-masked]'" <[email-masked]>, 
> >> [email-masked]
> >> >Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - 
> >> comments) (SHOULD be ,  
> >> RE: Issue #4)
> >> >Date: Wed, 11 Jul 2001 15:00:32 -0400
> >> >
> >> >Pat:
> >> >
> >> > The oAR does not need to know when the first packet arrival
> >> >at the newAR may occur. Indeed, for proactive to be effective,
> >> >the oAR must initiate a ct based upon an event that is 
> only indicates
> >> >a possible handover.
> >> >
> >> >  Here is the scenario: the MN traffic is passing 
> through, say, AR3.
> >> >The RF subsystem (aka the link layer, aka L2) "determines" 
> >> (through L1/l2
> >> >mechanisms) that AR5, AR19, and AR11 are potential 
> >> candidates for handover.
> >> >AR3 receives an event from L2 that instructs it to transfer 
> >> context to
> >> >AR5, AR19, AR11. The three "target" ARs in this example are 
> >> thus ready to
> >> >receive a handover of the MNs traffic, if it is required to 
> >> maintain the
> >> >traffic flow. Note that this approach does not completely 
> >> prevent the MN
> >> >from unexpectedly appearing in the coverage domain of a 
> >> different AR - 
> >> >that's the nature of wireless, however, it goes a long way 
> >> to improving
> >> >the situation.
> >> >
> >> >  Nothing in the above refers to a deadline event. Of 
> course, it is 
> >> >the objective to have the context in place before it is 
> needed at the
> >> >new AR. But ct must still work if this deadline is not met, 
> >> and, because
> >> >we all know how unpredictably handovers can be, the 
> requirements and
> >> >design should explicitly address this situation. In other 
> words, in
> >> >wireless handover, the exception is the rule.
> >> >
> >> >  As I have stated, I want to change that text to clarify 
> >> that ct completion
> >> >before the first packet arrival is a goal, not a 
> >> requirement. Or, perhaps,
> >> >it is a SHOULD, not a MUST.
> >> >
> >> >Gary
> >> >
> >> >Note: the ct scheme we are working on is a little 
> different then that
> >> >described above, but hte principle is the same. I did not 
> >> want to get into
> >> >all the details in this email.
> >> >
> >> >> -----Original Message-----
> >> >> From: Pat Calhoun [mailto:[email-masked]]
> >> >> Sent: Wednesday, July 11, 2001 10:34 AM
> >> >> To: Kenward, Gary [WDLN2:AN10:EXCH]
> >> >> Cc: 'Nakhjiri Madjid-MNAKHJI1'; [email-masked]';
> >> >> [email-masked]
> >> >> Subject: Re: [seamoby] L2 API (WAS: Ext. for FMIPv6 - 
> >> >> comments) (SHOULD
> >> >> be , RE: Issue #4)
> >> >> 
> >> >> 
> >> >> If we end up deciding that we want to keep most of the current
> >> >> text, I will follow the WG's desire, but I do have some
> >> >> concern with the fact that it currently uses the arrival of
> >> >> a packet destined for the MN as the main difference between both
> >> >> modes of operation. My issue here is in source triggers 
> >> (meaning oAP
> >> >> initiates CTP), oAP has no way of knowing when the first 
> >> packet will
> >> >> be received, and therefore doesn't know whether a proactive or
> >> >> reactive CTP should be initiated. This is why I am 
> >> convinced that this
> >> >> is just informational, and not a protocol thing.
> >> >> 
> >> >> PatC
> >> >> 
> >> >> On Wed, Jul 11, 2001 at 10:20:20AM -0400, Gary Kenward wrote:
> >> >> > Madjid:
> >> >> >  
> >> >> >    I'm glad you feel this way. I guess this discussion 
> >> >> began as a result of 
> >> >> > Issue #4, which proposes an alternate wording.
> >> >> >  
> >> >> >     After a few exchanges with Cedric, I reviewed the 
> >> >> current text, and
> >> >> > I realized that it indicates that proactive is deadline 
> >> >> driven, which I
> >> >> > really
> >> >> > believe is a bad thing to require.  All I want to ensure is 
> >> >> that there is a 
> >> >> > capability with ctp to start a ct sometime before the 
> >> >> actually traffic
> >> >> > handover
> >> >> > is initiated. Why? Because there are many networks that 
> >> >> provide "warnings"
> >> >> > that a handover may be imminent (actually, most RF systems 
> >> >> can be designed
> >> >> > to do this, and should). How? Well, the actual trigger 
> >> >> event will change
> >> >> > depending upon the L2 design, but typically, the mechanism 
> >> >> starts with the
> >> >> > base receiver sensing transmission from a mobile, and then 
> >> >> usually many
> >> >> > other 
> >> >> > mechanisms that kick in to identify the mobile at L1/L2.
> >> >> >  
> >> >> >    So, I would also like to keep the current text, for the 
> >> >> same reason. I
> >> >> > would
> >> >> > like to remove the deadline, or at least change it so that 
> >> >> it is clearly a
> >> >> > desirable
> >> >> > deadline, but not a requirement (we cannot make it a 
> >> >> requirement because the
> >> >> > physics
> >> >> > of wireless handover make the timing of any forewarning 
> >> >> event completely un-
> >> >> > predictable).
> >> >> >  
> >> >> >    Maybe I've said this all before, and maybe my view is 
> >> >> clear to everyone.
> >> >> > Sorry
> >> >> > for being repetitive.
> >> >> >  
> >> >> > Gary
> >> >> >  
> >> >> > 
> >> >> > -----Original Message-----
> >> >> > From: Nakhjiri Madjid-MNAKHJI1 
> >> [mailto:[email-masked]]
> >> >> > Sent: Tuesday, July 10, 2001 6:37 PM
> >> >> > To: Kenward, Gary [WDLN2:AN10:EXCH]; 
> [email-masked]';
> >> >> > [email-masked]
> >> >> > Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - 
> comments)
> >> >> > 
> >> >> > 
> >> >> > Gary,
> >> >> >  
> >> >> > I don't think we should remove the reactive/ proactive 
> >> >> definitions out of
> >> >> > requirement, unless there is a consensus for removing it.
> >> >> >  
> >> >> > If we nobody can come up with a better definition than 
> >> the already
> >> >> > existing one, either we keep it or declare it as an 
> open issue.
> >> >> >  
> >> >> > Personally I liked the definitions that are based on the 
> >> >> starting event
> >> >> > such as link establishment better, but I still can live 
> >> >> with the exiting 
> >> >> > one (packet arrival) for the time being. Removing the 
> whole thing
> >> >> > is throwing a lot of good thoughts away.
> >> >> >  
> >> >> > A requirement subject to modifications is better than no 
> >> >> requirement.
> >> >> >  
> >> >> > Madjid
> >> >> >  
> >> >> >  
> >> >> > 
> >> >> > -----Original Message-----
> >> >> > From: Gary Kenward [mailto:[email-masked]]
> >> >> > Sent: Tuesday, July 10, 2001 8:53 AM
> >> >> > To: [email-masked]'; [email-masked]
> >> >> > Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - 
> comments)
> >> >> > 
> >> >> > 
> >> >> > 
> >> >> > John: 
> >> >> > 
> >> >> >    I have been contemplating removing the 
> "reactive"/"proactive" 
> >> >> > definitions from the requirements also, but I really 
> do hope we 
> >> >> > do not lose the concept of starting ct as early as 
> >> possible. Being 
> >> >> > proactive with ct has been a fundamental component to ct 
> >> since the 
> >> >> > problem statement draft, and, to me, a critical tool for 
> >> providing 
> >> >> > seamless service handover. 
> >> >> > 
> >> >> >    There are those who, rightfully, have no interest in 
> >> proactive 
> >> >> > ct for their networks. If we lose the requirement, it 
> >> may be very 
> >> >> > difficult for the wg to proceed with a ctp design 
> that supports 
> >> >> > this mode. 
> >> >> > 
> >> >> >    I'll wait for your issue to be generated. Some of 
> us are also 
> >> >> > struggling with some alterative wording of the definitions 
> >> >> > 
> >> >> > Gary 
> >> >> > 
> >> >> > > -----Original Message----- 
> >> >> > > From: [email-masked] [ 
mailto:[email-masked]
>> >> > <mailto:[email-masked]> ] 
>> >> > > Sent: Tuesday, July 10, 2001 1:59 AM 
>> >> > > To: Kenward, Gary [WDLN2:AN10:EXCH]; [email-masked] 
>> >> > > Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - 
>> comments) 
>> >> > > 
>> >> > > 
>> >> > > Hi Gary, 
>> >> > > 
>> >> > > >  I agree, particularly with your definition of ct 
>> (although I'm 
>> >> > > > not sure where "reductive mode" came from). 
>> >> > > 
>> >> > > 
>> >> > > Ooops, I meant that I was in "reductive mode" (trying to 
>> >> > > simplify & get back to the basics).  
>> >> > > 
>> >> > > > In thinking through the overall discussion, I am 
>> >> realize that the 
>> >> > > > big difference between "reactive" and "proactive" is 
>> >> how they are 
>> >> > > > triggered. "proactive" assumes that there is a trigger 
>> >> available 
>> >> > > > early on that permits some context transfer in advance 
>> >> of an actual 
>> >> > > > handover. 
>> >> > > 
>> >> > > I agree. My thoughts are that the discussion of reactive 
>> >> and proactive 
>> >> > > (& triggering, etc.) get quite close to protocol 
>> design.  I think 
>> >> > > that is one reason that the discussion became so heavy on the 
>> >> > > the requirements. 
>> >> > > 
>> >> > > >   I do believe the current wording for proactive is 
>> >> wrong. Now that 
>> >> > > > I have had time to contemplate the wording, it does not 
>> >> define what 
>> >> > > > I have always believed proactive ct should be about. 
>> I'm hoping 
>> >> > > > that if we fix that wording, we can move on to the 
>> >> important part 
>> >> > > > of designing ctp. 
>> >> > > 
>> >> > > My suggestion would be to cut-out of the requirements 
>> >> document the 
>> >> > > discussion about proactive & reactive text.  I will try 
>> >> to make an 
>> >> > > issue for this later in the day. 
>> >> > > 
>> >> > > thanks, 
>> >> > > John 
>> >> > > 
>> >> > 
>> >> 
>> 
>>

---

From: Pat Calhoun <[email-masked]>
Date: Wed, 11 Jul 2001 13:31:37 -0700

I second Gary's comment below.

PatC