Subject: RE: [seamoby] proactive and reactive CT definitions

From: "Gary Kenward" <[email-masked]>
Date: Thu, 21 Jun 2001 16:58:02 -0400

Rajeev:

I'll try to think of some new wording. I'd appreciate it if
anyone else had a suggestion. 

Just to be clear, I am not sure exactly how Pat wants us to 
resolve the issues posted, but I will not be make changes to 
the requirements until their is a clear consensus capture on 
the www page (I think that's how its supposed to happen). This
includes issues I might have with the current wg doc ;^} .

Cheers,
Gary

Some questions/comments below:

> -----Original Message-----
> From: Rajeev Koodli [mailto:[email-masked]]
> Sent: Thursday, June 21, 2001 4:29 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: [email-masked]
> Subject: Re: [seamoby] proactive and reactive CT definitions
> 
> 
> Gary Kenward wrote:
> 
> >
> >
> > >
> > > Rajeev: The benefit is a clear starting point for the CT
> > > process. (i.e.,
> > > when to initiate CT)
> >
> > True enough, but the problem is that it is an event that happens too
> > late.
> > Certainly, for some networks, this may be the only handover 
> event that
> >
> > is visible at L3. But, for many networks, there are L2 triggers, and
> > mobility
> > events that can be forwarded to CT.
> >
> > In this sense, the definition you have provided is too limited.
> > Perhaps
> > the answer is to define another phase. I have no real ideas 
> on this at
> > the
> > moment: how about proactive, reactive and panic ;^}
> >
> 
> Rajeev: Given that you agree (at least partially) that in 
> some networks,
> (or "inter-networks") IP message after the link is established is the
> only way you could request CT, I would argue that the current
> definition, which is based on L2 triggers and "mobility 
> events", is too
> limited. It is ironic that we are debating whether to use IP messaging
> to request CT once the link is established..

I agree that there is one requirement that implies that all triggers are
originated at L2. This needs to be fixed. It was never intended that way.
(It's the requirement to "hide" the specifics of an L2 trigger).

I think I'll post a rewording for that requirement to make it more neutral,
ok?

> 
> >
> > > Rajeev: The offered definition does not say anything 
> about how long
> > > context transfer takes place. The _start_ of CT request is
> > > the issue. A
> > > packet arrives at the new AR (e.g., a MN request for CT), there is
> > no
> > > context there, then you fetch it.
> >
> > Ok. How CT starts is important. But as important is when it 
> finishes.
> > Indeed, it is more important to me, as I see too little value in ct
> > that
> > finishes after 3 or 4 packets have been forwarded. I want ct to make
> > real-time
> > handovers opaque to the end-user.
> >
> >
> 
> Rajeev: While I don't necessarily agree with the example, we all want
> CT to finish before the packets start arriving. That's why we have
> predictive handovers. When you can't do such a thing, e.g., consider
> that link-layer triggers don't work because the two technologies are
> different, you have the initiation of reactive CT after the MN
> establishes a new link.

I definitely believe this can happen. I am aiming for the requirements to be
inclusive. I also don't see how the above has much to do with the first
packet 
arrival at the new AR. It seems to have more to do with an MN initiated L3
trigger, correct?

> 
> 
> > > > If the context is not in place for the first packet forwarding,
> > then
> > > > the transfer is reactive; meaning that at this point, 
> the goal is
> > to
> > > > complete the transfer as fast as possible to minimize 
> the delay in
> >
> > > > forwarding that first packet.
> > > >
> > >
> > > Rajeev: Exactly. This is what I am proposing to be added.
> >
> > But this is in the current requirements. It just doesn't say that
> > reactive
> > starts with the first packet forwarding, accounting for the 
> fact that
> > in some
> > networks, reactive mode can occur before that event.
> >
> 
> Rajeev: Is it possible to re-word it such that it takes care of the
> issue we have raised ? Can we say that reactive CT takes place as a
> consequence of MN establishing a new link ?
> This would be sufficient.

Well, we could, but I'm unclear as to why you don't see that with the
current requirements (at least once the problem with the L2 requirement is
fixed). Everyone appears to agree that the origin of the triggers is not
important, as long as the trigger manifests itself at L3 (probable as a
control message) and has certain, as yet unspecified characteristics).

The scenario you describe above could be resolved with either an L2
initiated trigger or an MN initiated trigger, could it not?

If you were thinking of the trigger being the first IP data packet from the
MN to hit the new AR, then that's fine (it may be a little late) - the new
AR would simply have to filter incoming packets. There's big questions about
what would happen next, but that's solution space.

> 
> >
> > >
> > > >
> > > > Reactive CT is when I either choose not to perform proactive CT,
> > or
> > > > I fail to meet the goal of being proactive.
> > >
> > > Rajeev: Agreed.  Can we add the text then ? What do others think ?
> >
> > It seems to me that the only part that we disagree on is what
> > indicates that "reactive mode" is occurring.
> >
> 
> Rajeev: Yes, and some text along the above lines would do it.
> 
> Regards,
> 
> -Rajeev
> 
> 
> >
> > >
> > > Regards,
> >
> > Onwards and upwards,
> > Gary
> >
> > >
> > > -Rajeev
> > >
> > >
> > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Rajeev Koodli [mailto:[email-masked]]
> > > > > Sent: Wednesday, June 20, 2001 2:49 PM
> > > > > To: [email-masked]
> > > > > Subject: [seamoby] proactive and reactive CT definitions
> > > > >
> > > > >
> > > > >
> > > > > Description of issue :Clear, unambiguous definitions are
> > missing.
> > > > >
> > > > > Submitter name: Rajeev Koodli
> > > > >
> > > > > Submitter email address: [email-masked]
> > > > >
> > > > > Date first submitted: June 20, 2001
> > > > >
> > > > > Comment type: 'T'echnical
> > > > >
> > > > > Priority:  ''S'/MUST fix
> > > > >
> > > > > Section:  4.5
> > > > >
> > > > > Rationale/Explanation of issue:
> > > > >
> > > > > The section provides the description of proactive and reactive
> > > > > CT without properly defining what they are. We need the
> > > definitions.
> > > >
> > > > >
> > > > > Requested Change:
> > > > >
> > > > > Reactive CT: The context transfer process which takes place
> > > > subsequent
> > > > > to arrival of a MN's packet at the target AR
> > > > >
> > > > > Proactive (I prfer Charlie's Predictive better) CT: The
> > > > > context transfer
> > > > > process in which the required contexts are in place at
> > > the target AR
> > > >
> > > > > prior to the arrival of MN's packet at target AR.
> > > > >
> > > > >
> > > > >
> > > > >
> > >
> > >
> 
>

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 21 Jun 2001 15:22:47 -0700

> includes issues I might have with the current wg doc ;^} .

well, I am rather confused in this whole thread, but I am trying
to catch up. So, do folks generally feel that a change is required?
If so, could we get some proposed text that we could sink our
teeth into?

If there are additional changes that are being proposed, unless they
are purely editorial in nature, and MAY cause some commotion, then
I think an issue should be opened. Once we agree on the wording (read:
proposed text), then we can accept the text and close the issue.

So far, I just see some people agreeing to nothing particularly 
concrete :(

PatC

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 21 Jun 2001 16:15:18 -0700

Hi Pat,

I did open an issue, and I proposed the text. See at the bottom of this e-mail.
We need to revise it a little bit now.

So, here is the proposal for revised definitions:

Reactive CT: The context transfer process which takes place subsequent to the MN
establishing a new link with the new AR.

Proactive CT: The context transfer process in which the contexts are present at
the new AR prior to the arrival of MN's packets at the new AR.

Charlie: would you consider revising it further ?

Regards,

-Rajeev

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 21 Jun 2001 16:07:16 -0700

> We need to revise it a little bit now.

right.

> Charlie: would you consider revising it further ?

and other folks, too, of course :)

Do folks generally favor such a change?

PatC

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 21 Jun 2001 16:32:39 -0700

> Do folks generally favor such a change?

I prefer this change. its much more clear and concrete and would 
stop further debate on what proactive and reactive CT mean.

Vijay

---

From: Charlie Perkins <[email-masked]>
Date: Thu, 21 Jun 2001 21:38:22 -0700

Hello Pat,

> > the new AR prior to the arrival of MN's packets at the new AR.

I would suggest that for Proactive context transfer, we should allow for the
possibility that some of the context may still be in transit when packets begin
to arrive for the mobile node at the new access router.

One other characteristic is that reactive is a "context pull" operation,
and proactive is a "context push" operation.  They could still both
use the same protocol message to deliver the context, though.
In other words, as I understand "proactive", the previous access
router predictively sends the context to a new access router
(selected by some unspecified means, presumably initiated by
some radio network controller).  Reactive transfer, on the other
hand, would typically be initiated by the new access router
sending a request for context transfer to the previous access
router.  In many systems that reactive request might actually
be triggered by a message from the mobile node, but the
actual context transfer request would more likely seem to have
emanated from the new access router.

Regards,
Charlie P.