Subject: [seamoby] CT trigger or CT completion? was: proactive and reactive CT defi nitions

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Thu, 21 Jun 2001 12:07:52 -0500

Rajeev, 
 
I think, I know what the problem is:
The draft bases the definition of Proactive and reactive on
when the handover (packet arrival) COMPLETE	S.
You, on the other hand, are basing you definition on the START
of CT, i.e. CT trigger. 
I think the drafts approach is better FOR NOW since, we have not completed
the frame work discussion yet (we did have a discussion about Mobility
framework, and I did ask the question of whether the scope is Mobile IP
or not, of the very same reason).
When you don't know what your underlying layer 2 technology or your
Layer 3 mobility baseline is, then you have to speak in common, general
terms, such as packet arrival.
Start of CT can be based on all kinds of things:
Example From Mobile IP fast handover perspective:
	1-Solicitation for proxy router
	2-Binding update
	3-Neighbor advertisement from Mobile
Example From a link layer perspective
	1-Pilot beacon/ signal strenght measurement
	2-RLC/P/ RNC scheduler directive
	3-Mobility management unit
	......
From a CNP network that is doing more advance next router discovery
there could be other types of signals, especially for proactive, 
you are understimating the beyond 3G scenarios.

So which CT trigger do you want to pick?

Earlier trigger + less amount context + higher AR-AR bandwith
leads to a faster CT (more chance for proactive).
A slow handover solution (base Mobile IP) waits for L2 HO completion and
then starts L3 signaling, a faster handover solution starts earlier.

So we are talking about a race condition between CT and HO if
we don't know the details of the system, so we base
the definition on CT completion and that is why we
simply say, if the CT is done prior to packet arrival, then
it is proactive, if not it is reactive.

two months ago, I was screaming for an event sequence out of
the handoveer procedure for  timing requierement,
I suggested to define CT triggers and CT deadline based on the
event sequence
I  asked YOU for a HC based CT deadline event, I don't remember you offering
any?
I also suggested that we would prioritize features and 
then set a halfway CT deadline for reactive, so that by that deadline
 only the time critical feature contexts are through and again used HC
as example.

So why are we in a different situation now?

****Unless you offer a clear event sequence and show different Handover
stages and the need of packet delivery for various feature context,
I don't think we can change our definition and base it on an start
event.*****

****Furthermore, I think Kulwinder issue #2 covers this aspect.
Unless you want to 

As I said in my other email: 
It seems you are questioning the usefulness of CT and its role
on the timing of the events, if you think the packets can be
delivered and then you establish HC context and re-negotiate authentication
and other things, then why is CT timing so critical, you are contradicting 
yourself.

Regards,
Madjid

-----Original Message-----
From: Rajeev Koodli [mailto:[email-masked]]
Sent: Wednesday, June 20, 2001 5:11 PM
To: Nakhjiri Madjid-MNAKHJI1
Cc: [email-masked]
Subject: Re: [seamoby] proactive and reactive CT definitions

Hello Madjid,

Nakhjiri Madjid-MNAKHJI1 wrote:

> I still don't know whether I should respond to these issues or not,
> but it seems that is the going trend.
>

Rajeev: It's a good going trend to straighten things out.

>
> For Proactive, your definition works, and actually it is the same
> as in the draft.
>
> I think this definition of reactive is going backward a bit.
> We did discuss this issue at length and I think you were in agreement that
>  reactive CT, does not always mean that CT cannot start until after the
MN's
> packets have arrived.

Rajeev: Reactive CT means that there is no context at the new AR when MN's
packets arrive. If we want to do CT, I would think that that's a good time
to
start.
Going by your argument, when do you start a reactive CT ? If we both agree
that
there is no context in place when the MN's packets arrive, what do you do ?
If
you had started CT before, that's proactive, but not working very well.
Claiming that reactive CT is the "proactive CT gone bad" is extremely poor
definition. I don't believe that I agreed at  all to such a definition.
Please
enlighten me!

>
> For reactive, CT can happens simultaneous as Handover signaling
> but it might not finish when handover signaling is complete.

Rajeev: Where is this definition ? This can take another avatar of its own
:-)

>
>
> What you are suggesting, means that you don't need CT to deliver
> packets the mobile and are totally moving CT out of the critical
> path for timing. I guess say for header compression
> it means that the newAR does not have HC states for a while,
> assuming it can receive uncompressed packets,
> But would this work for security and authentication, I don't think so.
>

Rajeev:  If the context is not present when the MN's packet arrive, you try
to
get it. Right ? Why is that not reactive CT ? If CT is not there, and while
I try to fetch it, why can't I forward the packets if it is possible ? If
I *don't* forward packets, what do I do ? Drop them ? How's that good for
TCP/RTP's performance ? Consider the ability to send and receive normal IP
packets as a service (aka connectivity) upon which the rest of the CT
features
are based.

For HC, you could forward on downlink. For security, you could forward the
packets in both the directions until you receive the appropriate contexts.
You
may not have a packet *treated* with require feature, but you can still
forward
packets. If CT fails all together, what do you do ? You could require the MN
to
re-authenticate itself. How do you do that ? You need connectivity to send
and
receive IP packets.
In a nut shell, if there are no contexts, you can always go fetch them *or*
require the MN to re-establish them.

>
> I like the current definition for reactive:
>  "doing CT when handover is imminent" and that means that oldAR or
> newAR are already engaged in handover signaling, now this could be
> a L2 trigger that newAR has received or a HI or something else, but
> it does not mean completion of handover signaling and packet routing
> change.
>

Rajeev: When would you start CT in this case ? When does new AR receive L2
trigger ? Is it trying to do CT when it receives a HI ?

I understand that when a packet arrives at new AR, the CT may be already "in
progress", as indicated by the signaling that has taken place. The new AR
may
*still* initiate CT signaling and the old AR must be able to handle requests
that come in sequence. It is called "idempotent" operation.

Regards,

-Rajeev

>
> Madjid
>
> -----Original Message-----
> From: Rajeev Koodli [mailto:[email-masked]]
> Sent: Wednesday, June 20, 2001 1: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 13:39:34 -0700

Hello Madjid,

I hope you don't mind if I edge a word in between.

> when the handover (packet arrival) COMPLETE     S.

But the problem could be that the term "handover" is
not sufficiently crisp to carry out the discussion.
The concept of link establishment, however, is crisp
enough.  I would like to suggest using the latter term.
I would define it as follows:

- A link establishment has occurred when a mobile node becomes
  able to send a packet to the access router

This does NOT say that the mobile node is REQUIRED to send
a layer-3 packet before the link is established -- only that
it _could_ send a layer-3 packet.

Then, my definitions about reactive vs. predictive/proactive
context transfer initiation are equally precise.

> or not, of the very same reason).

Basing the definitions on link establishment avoids completely any
questions about Mobile IP.

> terms, such as packet arrival.

Even packet arrival is quite susceptible to ambiguity:

- Is it that a packet arrived, or that it MIGHT have arrived?
- What packet is it that arrived?
- Did it arrive at the mobile node, the previous access router, or
  the new access router?

>         3-Neighbor advertisement from Mobile

The Mobile IP fast handover allows layer-2 triggers also.

> then starts L3 signaling, a faster handover solution starts earlier.

Of course everyone wants to have reliable predictive handovers.
But for systems that cannot fit within that design parameter
it would still be nice to have fast reactive handovers.  It is
not a fair criticism of reactive handover to insist that proactive
is better.  And similarly for reactive context transfer.

> it is proactive, if not it is reactive.

I still think this is questionable, given my objections above
to the notion of "packet arrival".

> the handoveer procedure for timing requirement,

First, the deadline for various kinds of context transfer
will be different.  Secong, the context transfer protocol
might be definable without regard to the specific kind of
trigger.  For layer-2 triggers, this seems pretty clear!

> I don't think we can change our definition and base it on an start

I'm not sure if my example would be welcome, but here goes
anyway:

1) Mobile node shows up at new access router (802.11, say)
2) Mobile node asks new access router to collect context
   from previous router.  Mobile includes authentication data
   that can be checked by previous access router.
3) New access router sends request for context transfer to
   previous router.
4) Previous access router checks the authentication data, and
   upon approval delivers the requested context features
5) New access router installs the delivered context features,
   and (optionally) notifies the mobile node about the status.

This is reactive, and it could be very valuable for certain
kinds of context.

> and other things, then why is CT timing so critical, you are contradicting

I'm really puzzled by this question.  There is a certain time
budget (say, as defined by the VoIP parameters).  It would be nice
to have the fastest possible context transfer in order to remain
within that time budget.  It's easier to do so with proactive
context transfer.  It's still possible to do so with reactive
context transfer.  Not all systems will support proactive context
transfer.

Am I missing the point of your question??

Regards,
Charlie P.

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 21 Jun 2001 14:21:42 -0700

Hello Madjid,

I have some comments below. I hope it is sufficient to reply to this e-mail
alone (since you pointed to this one in the other e-mail).

Regards,

-Rajeev

> terms, such as packet arrival.

Rajeev: Do we _need_ to know what the underlying L2 technology is for our
purpose here ? I would hope not. CT must work across all L2 technologies. In
some networks, you could make use of L2 triggers; that does not mean that we
need to know them and base our definitions (only) on them.
Regarding L3 mobility baseline: it would help to know it. However, I would
argue that it is not needed for the reactive CT definition. What if we use
Charlie's suggestion that reactive CT happens once the MN establishes a new
link ? This does not depend on any L3 mobility baseline.

>         3-Mobility management unit

Rajeev: As I said in the last sentence above, we could simply say that reactive
CT takes place after the MN establishes a new link. No L2 idiosyncracies, no
dependence on L3 mobility mechanism.

> it is proactive, if not it is reactive.

Rajeev: I can see the race conditions if you don't specify the start epoch
clearly. If you agree that doing CT _after_ packet arrival is reactive, we are
in agreement!

> I  asked YOU for a HC based CT deadline event, I don't remember you offering

Rajeev: Oops, you can take it that it was unintentional. With so much e-mail
load, I hope you would symphathize!
Anyway, do you think that this is still important ? I think that base
definitions would suffice for the moment.

> I don't think we can change our definition and base it on an start

Rajeev: Well, it appears that this is an important issue to you as well. My
suggestion is that we provide basic defintions in the requirements draft. And,
we could state the defintions based on whether CT is initiated while the
MN still has the link with the old AR or it is initiated after the MN
establishes a new link with new AR. That should suffice.

If you insist that we need to provide the event sequence, I would be happy to
provide them from CT framework draft we submitted for SD IETF.

> and other things, then why is CT timing so critical, you are contradicting

Rajeev: I am not questioning the usefulness of CT. I am trying to provide
better definitions that would make it feasible to implement it on any L2
network. I hope it is ok to claim that it is a useful purpose.

We clearly agree that predictive CT would try to place contexts before the
packet arrival at new AR. When this is not possible to achieve, you have to
fallback on obtaining the contexts once the MN attaches to the new AR. In any
_generic_ network topology, you cannot assume that L2 handover events/triggers
would help us accomplish CT. And, we are chartered to develop CT without
assuming specific L2 support (NOTE: this does not mean that you don't make use
of L2 assistance). So, when predictive is not possible, doing reactive CT could
mean a performance hit.
That does not mean contradiction; it is stating the fact!

As I have said in few e-mails now, when there are no contexts at new AR, what
do you ?

1. fetch contexts. The signaling could already have started. Until the contexts
arrive, what do you do with the packets?

2. re-establish contexts. Until the contexts are re-established, what do you do
with the packets ?

In both 1 and 2, you could drop them or forward them without treating them with
the feature contexts. The choice is up to you. We know that there is value in
forwarding the packet or buffering it. In any case, I don't see any
contradiction!