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 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:30:16 -0700

> wireless handover, the exception is the rule.

Good. So far we are in agreement.

> it is a SHOULD, not a MUST.

Right but using the above example, there is *nothing* the protocol
can do to ensure this happens. This is network engineering, wireless
technology capabilities, etc.

So, this requirement is kind of moot, since we agree that the protocol
doesn't care, and the packet would be identical regardless of whether
the CT occurred prior to the arrival of the first packet. I think it 
still makes sense to discuss timing in the protocol spec, but this is
informative only.

Am I simply confused?

PatC