Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments)

From: "Gary Kenward" <[email-masked]>
Date: Wed, 4 Jul 2001 09:35:12 -0400

Just a note to cover what I believe is a possible misinterpretation
that can be made from John's and Madjid's recent emails.

  The issue with triggers has nothing to do with "terminology" (yet). 
The issue with triggers has to do with the fact that there are a 
plethora of possible triggers that can be used. If we identify one
trigger in the requirements, then we need to identify either all, or a 
comprehensive set of examples. This is not "specmanship" - given 
that these triggers control ct, this is one of the most important 
issues to be resolved.

  I'm still not convinced that it is worthwhile trying to solve it 
in a requirements document.

Gary

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, July 04, 2001 3:14 AM
> To: [email-masked]; [email-masked]
> Subject: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments)
> 
> 
> Hi James,
> 
> > In fact, I am preparing just such a draft as we speak. The 
> > intent is to take the material from the BETH draft and from 
> > the FMIPv4 draft and perhaps add something on the link with 
> > Seamoby context transfer.
> 
> I think this would be extremely worthwhile.  It seems that 
> SeaMoby is currently struggling over terminology about
> triggers, etc. with respect to handovers.  I'd even suggest
> that interested parties from both MIP & SeaMoby get together
> in London to discuss how to move forward.  Perhaps it would 
> be a good thing if MIP & SeaMoby could work together on this
> issue - in order to assure that the resultant work suits both
> groups.
> 
> best regards,
> John
>

---

From: James Kempf <[email-masked]>
Date: Fri, 06 Jul 2001 22:24:30 -0700

Gary,

I agree that detailed analysis of triggers should be in the protocol doc, not
requirements. The requirements might say something to the effect
that the protocol should use triggers if available.

                 jak

At 09:35 AM 7/4/01 -0400, Gary Kenward wrote:

> > From: [email-masked] 
> [<mailto:[email-masked]>mailto:[email-masked]]

---

From: [email-masked]
Date: Mon, 9 Jul 2001 09:48:56 +0300

Hi James,

> There is a draft in preparation with people from both Seamoby
> and MIP on the author list. These are people with whom
> I have talked and who have expressed interest in working on such a
> draft over the last year. The draft has a section on L2 triggers
> that came out of the MIP fast handoff work, then a section
> that describes connections with Seamoby context transfer.
> I expect we will have it complete by next Fri.'s 00 deadline.
> 
> We have already talked to the MIP WG chairs about getting
> time on the agenda to discuss the draft, what I'd like
> to suggest is that we do the same for Seamoby. That
> will give both WGs the opportunity to review and comment
> on the draft. I will talk with Pat about that when he gets
> back from vacation.

I think that is a good idea & I'm glad to see that authors
from both MIP & SeaMoby are on it.  That's enough for me.
I look forward to the draft.

br,
John

---

From: [email-masked]
Date: Mon, 9 Jul 2001 09:55:36 +0300

Hi James & Gary,

> I agree that detailed analysis of triggers should be in the 
> protocol doc, not requirements. The requirements might say 
> something to the effect that the protocol should use triggers 
> if available.

Agreed.

> >   Just a note to cover what I believe is a possible 
> > misinterpretation that can be made from John's and Madjid's 
> > recent emails.
> >
> >   The issue with triggers has nothing to do with 
> > "terminology" (yet). The issue with triggers has to do with the 
> > fact that there are a plethora of possible triggers that can be
> > used. If we identify one trigger in the requirements, then we need to 
> > identify either all, or a comprehensive set of examples. This is not 
> > "specmanship" - given that these triggers control ct, this is one of 
> > the most important issues to be resolved.
> >

I think the use of triggers (which events, etc) and what to call them
should be left to an other document.  In reductive mode, this is 
what I see:

	1) Something starts a process in an AR to transfer some
	blob to another AR.  

That is what context transfer means to me!

I think (if someone wants to produce it), a document which outlines the
different 'something' which starts the CT off, would be a good document.
If such a document would be fairly complete, we could then examine what
we would need when it came to design a protocol.

Could I suggest that we try a new way of working within SeaMoby?  We
keep the documents thin.  I think if we had several documents, each
outlining an issue, we would then have a robust set of issues & 
documents to go forward with.  

best regards,
John

---

From: "Gary Kenward" <[email-masked]>
Date: Mon, 9 Jul 2001 10:46:46 -0400

John:

  I agree, particularly with your definition of ct (although I'm
not sure where "reductive mode" came from). 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.

  The completion of ct, regardless of the mode, is as soon as
possible for the context to be used in forwarding the MNs packets.
Completion can be define relative to a particular even such as
the first packet arrival, but it cannot be synchronized to any
event because of the reality of the physics of wireless handover.

  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.

Gary

> Sent: Monday, July 09, 2001 2:56 AM
> To: [email-masked]; Kenward, Gary [WDLN2:AN10:EXCH];
> [email-masked]
> Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments)
> 
> 
> Hi James & Gary,
>

---

From: [email-masked]
Date: Tue, 10 Jul 2001 08:58:32 +0300

Hi Gary,

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

> that if we fix that wording, we can move on to the important part 

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: "Gary Kenward" <[email-masked]>
Date: Tue, 10 Jul 2001 11:16:42 -0400

I tend to agree with you Pat, however, without a ctp design
we really do not know. The fundamental issue I have is for
us not to lose the concept of doing things as early as possible.
It would be quite easy to define a ct protocol that could not
be proactive - e.g. a ctp that was triggered by the first packet
arrival at the new AR.

Gary

> From: Pat Calhoun [mailto:[email-masked]]
> Sent: Tuesday, July 10, 2001 10:57 AM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: [email-masked]'; [email-masked]
> Subject: Re: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments)
> 
> 
> On Tue, Jul 10, 2001 at 09:53:08AM -0400, Gary Kenward wrote:
> > 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.
> 
> My view, Gary, is this that reactive/proactive is simply a method of
> using CTP. I don't see how the protocol could be that different when
> used in either mode. Perhaps some text at the beginning of 
> the protocol
> specification detailing its use in proactive and reactive modes would
> be sufficient.
> 
> This really comes down to the triggers available for CTP, and is not
> a CTP protocol issue.
> 
> PatC
> >    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
> > 
> > > Sent: Tuesday, July 10, 2001 1:59 AM
> > > To: Kenward, Gary [WDLN2:AN10:EXCH]; [email-masked]

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Tue, 10 Jul 2001 17:21:30 -0500

Since my name was mentioned :) Actually, I think the issue of triggers
IS important for how you define proactive and reactive, especially if the 
definition is based on an starting event for CT, as opposed to based on when
CT ends.
 
I agree that we might not be interested in specifying a specific
L2 signal (since it would be technology independent) but we 
cannot set  CT timing requirements (if that is the goal here) without 
knowing when the CT starts.
 
Madjid

-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Wednesday, July 04, 2001 8:35 AM
To: [email-masked]
Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments)

Gary 

> From: [email-masked] [ mailto:[email-masked]
<mailto:[email-masked]> ]

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Tue, 10 Jul 2001 17:37:05 -0500

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: 

Gary