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

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Thu, 12 Jul 2001 17:02:10 -0500

-----Original Message-----
From: Pat Calhoun [mailto:[email-masked]]
Sent: Wednesday, July 11, 2001 9:34 AM
To: Gary Kenward
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.

MN>> ok, this is a good point, are we envisioning different CTP
functionality between proactive and reactive case? If yes, then it 
is definitely a problem!!

 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: Fri, 13 Jul 2001 12:49:57 -0700

> is definitely a problem!!

The sense I read at the moment is that these are modes of
operation more than protocol issues. I believe that these modes
should be described in the protocol spec, to guide implementors
of CT and link layers, but that's as far as it needs to go (IMHO).

PatC