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

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Thu, 21 Jun 2001 16:17:54 -0500

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.

Ajoy: I thought some more about inter-technolgy CT. It seems
the inter-technolgy CT may be difficult to realize. For 
example, one access network might use PPP while others
might not. In this case, will it make 
sense to transfer the PPP context from one access router to 
other? Additionally, I think most of us agree that make before 
break handover is possible in inter-technolgy case, when 
some overlap is available between coverage area of 
different technolgies. So Can't
MN re-negotiate CT with new AR before breaking 
connection with oldAR ?

regards,
ajoy 

-----Original Message-----
From: Rajeev Koodli [mailto:[email-masked]]
Sent: Thursday, June 21, 2001 3:29 PM
To: Gary Kenward
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..

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

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

>
> >
> > >
> > > 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: Rajeev Koodli <[email-masked]>
Date: Thu, 21 Jun 2001 14:38:17 -0700

Singh Ajoy-ASINGH1 wrote:

> other?

Rajeev: probably not. But what's your point beyond that ?

> Additionally, I think most of us agree that make before
> different technolgies.

Rajeev: May be. May be not. I guess the point is can we depend on such
things for all the networks for which we want an IP-based mechanism to
work. The basic design principle should be to get the protocol to work on
all the link layers while allowing for link-specific optimizations, and not
the other way around (i.e., to design the protocol based on what is
available in some links that we are familiar with).

> So Can't

Rajeev: If the MN has link connectivity with the new AR and can send a
message, yes. Alternatively, it could use its existing link with the old AR
(proactive/predictive CT).

Regards,

-Rajeev

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 21 Jun 2001 15:13:03 -0700

> different, you have the initiation of reactive CT after the MN

It is possible or even likely that some packets could be delivered
to the mobile node before the context is transferred, especially
in the reactive case but not necessarily only there.  For example,
given proactive, what if the mobile node starts doing DAD at the
new access router before the context transfer completes?  This would
be quite possible, and I would hate to see the context transfer
protocol place any restrictions otherwise.  Obviously, if DAD is
needed, it would be silly to delay its initiation, even for
proactive.  If, instead, you want to make the definition that
this isn't "pro-active enough", then I would claim that the need
for redefinition exhibits the problem with even the general thrust
of the existing definitions.

> MN re-negotiate CT with new AR before breaking

Sure this can happen, but if inter-technology context transfer is
is available and it saves time, then we should allow it.  The
benefit will be better customer experience in more cases.  Furthermore,
I can't see any downside on the protocol design.  It doesn't seem to
make the problem harder or easier.  And I would hate to see PPP context
become the defining example for context transfer.

Regards,
Charlie P.