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

From: "Gary Kenward" <[email-masked]>
Date: Thu, 21 Jun 2001 11:15:13 -0400

Rajeev:

> -----Original Message-----
> From: Rajeev Koodli [mailto:[email-masked]]
> Sent: Wednesday, June 20, 2001 5:40 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: [email-masked]
> Subject: Re: [seamoby] proactive and reactive CT definitions
> 
> 
> Gary Kenward wrote:
> 
> >
> >
> > This is essentially the same definitions I proposed during
> > the discussion over proactive and reactive a few months back.
> > And, as someone pointed out, it was mistaken.
> >
> > The first question that was asked then, and is still apropos:
> > what benefit is derived from focussing on the specific arrival
> > event as the delineator?
> >
> 
> 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 ;^}

> 
> >
> > To explain further, let me illustrate with a scenario: suppose that
> > it takes 10ms to complete a context transfer; now suppose
> > that the ct trigger event happens  in less then 10ms from the
> > actual first packet arrival, say 9 ms - is this a proactive or
> > reactive ct? The ct that occurs fulfills neither of the offered
> > definitions.
> 
> 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.

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

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

> 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: "Charles E. Perkins" <[email-masked]>
Date: Thu, 21 Jun 2001 08:57:53 -0700

Hello Gary,

I think that, even if context transfer begins AFTER a node
finds a new point attachement, it is by no means necessarily
too late.  This can be made obvious by a simple example:
- What if a node does context transfer after a link establishment
  which finalizes .0001 second after the previous link is dropped?
If you agree with this, but have concerns about the .1ms latency,
then we are just haggling over numbers.  It shouldn't be the
place of the context framework document (for arbitrary media!)
to arbitrate this, as long as there are media for which the
context transfer can occur within meaningful time constraints.
I think it's clear that such media will exist.

So, I claim that the proposed definition for reactive is very
beneficial.  A reactive transfer is initiated after the new
link is established.  A predictive transfer is initiated
before the new link is established.  These definitions are
easy, clear, and useful.

Since even the definition of handover seems to be too muddy,
perhaps the definition for reactive/predictive (or, if we must
use it, the non-English word "proactive") should depend only
on link establishment.

Regards,
Charlie P.

> is visible at L3. But, for many networks, there are L2 triggers, and mobility
> finishes after 3 or 4 packets have been forwarded. I want ct to make real-time
> 
> starts with the first packet forwarding, accounting for the fact that in some

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 21 Jun 2001 13:29:01 -0700

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

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

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

> 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