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

From: "Gary Kenward" <[email-masked]>
Date: Tue, 10 Jul 2001 09:53:08 -0400

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]]
> 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: Tue, 10 Jul 2001 07:56:34 -0700

> 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

---

From: Cedric Westphal <[email-masked]>
Date: Tue, 10 Jul 2001 08:26:29 -0700

Pat,

> This really comes down to the triggers available for CTP, and is not

I do not agree with this. Let me give you an example: MN wants to use
proactive
CT for header compression state relocation. MN moves to new access router.
If the ctp is same for proactive and reactive, then MN can only _hope_ that
the header compression state is in place. So it transmits with a full header,
and loses
some of the benefit of the context transfer.
If proactive and reactive ct are different (and they don't necessarily have to
be very
different, consider just an Ack from newAR to MN via oldAR that context is in
place, or whatever, this is solution space) then MN can distinguish and use
compressed
header right away.
Take care,

Cedric.

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 10 Jul 2001 08:29:09 -0700

> place, or whatever, this is solution space) then MN can distinguish and use

so a bit set in the CTP would inform the receiver that the packet's
IP header is compressed? I'm not sure that I follow your example :(

The MN can initiate a CTP in proactive or reactive mode, but I still
think that the packet format would be identical.

PatC

---

From: Cedric Westphal <[email-masked]>
Date: Tue, 10 Jul 2001 10:25:14 -0700

> IP header is compressed? I'm not sure that I follow your example :(

Well, I did not elaborate the example since, as I said, it is solution space.
All I am trying to convey is that there is value in knowing before, say, releasing
connection
to oldAR, that the C is T'ed. And thus there is a difference (at least in the
requirement) between proactive and reactive.

> think that the packet format would be identical.

I agree with that. Packet format should be the same. But is the ctp only a matter of
defining a packet format? Or is it a ct protocol?
In my little example:
MN                                            oldAR
newAR
    will handoff to new AR-->                      transfer ct---->
                                                                 <-------Ack, ct
received
    <----------------Ack ct there

If MN is still connected to oldAR when the Ack gets back, then it is proactive, and
it knows it
can use, say compressed header right away.
If MN is not connected to oldAR when the Ack gets back, then MN knows it has not
received
it, and by default, it is reactive, and it uses full header with newAR.

I agree with you that the arrow    'transfer ct---->' should be the same, whether
it's proactive or
reactive. Now,  I am not sure it is the only arrow that is needed.

Take care,

Cedric.

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 10 Jul 2001 10:35:50 -0700

> reactive. Now,  I am not sure it is the only arrow that is needed.

Good, I think we are making progress.

So, the main difference above between proactive and reactive is the
presence of the header compression state blob. We couldn't, however,
mandate that particular blobs be present in proactive vs. reactive,
but as we discussed earlier, could require that certain blobs be
defined as high priority, which would be used in the initial CTP message
(in a multi-phasic sense) - the equivalent of proactive.

PatC

---

From: Cedric Westphal <[email-masked]>
Date: Tue, 10 Jul 2001 11:54:01 -0700

Pat,

sorry for using a header compression example, I think it is getting more confusing
that anything. The difference between proactive vs. reactive is not one of presence
of particular blobs.
What you mean here is a _relative_ timing of the different context establishments at
new AR, higher priority blobs arriving before lower priority blobs. This is not what
proactive vs. reactive is.
The way I see proactive, it is an _absolute_ timing of the event with respect to a time
reference outside of the context transfer. MN wants context to be in place before
MN's packets arrive at newAR, so MN requests proactive ct. MN needs to know whether
proactive has succeeded (be it by some acknowledgement, or whatever, solution space,
later). If not, then MN can make use of this information (by not getting the
acknowledgement,
or whatever).
If you can do everything, proactive and reactive, with the same protocol, it is fine with
me, but
this is a requirement phase, and I think you have a solution  in mind (and a
prioritization of
phases is only a solution to the relative ct timing problem).

Cheers,

Cedric.

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 10 Jul 2001 12:36:34 -0700

> phases is only a solution to the relative ct timing problem).

yes, you are correct. My thiking is in the solution space. Perhaps leaving
the distinction in the requirements can be useful during protocol design,
but I am still convinced that all that will be required are two sections 
decribing the timing of CTP, and no protocol changes.

PatC