Subject: RE: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Fri, 22 Jun 2001 18:02:16 -0500

Hi Charlie,

Comments below (MN>>)

-----Original Message-----
From: Charles E. Perkins [mailto:[email-masked]]
Sent: Thursday, June 21, 2001 3:40 PM
To: Nakhjiri Madjid-MNAKHJI1
Cc: [email-masked]
Subject: Re: [seamoby] CT trigger or CT completion? was: proactive and
reactive CT definitions

Hello Madjid,

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

MN>> I actually appreciate it :)

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

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.

MN>> I am not sure if I understand the sentence above, but
I take it as, by link establishment you mean the MN is able
to send and receive L3 packets.
The reason we picked Handover, was so we knew whether we were
introducing latency into handovers or not.

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

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

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

MN>> Please see my earlier email on the 3 cases.

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

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?

MN>> I agree, however, it is not very hard to change it, to say
Packet arrival at newAR (since that is what matters for CT).
Not having feature contexts might make the packet arrival defintion
fuzzier if you don't know how to interprete packets.
However, as I said you can replace packet arrival with an
almost equivalent event (say another message that makes packets arrive
at newAR).

MN>>point was to define a deadline for CT to be complete, and
basing everything on the starting event, does not provide any
timing requirements for CT, unless you want to leave it open
for now.

> 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

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

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

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.

MN>> Sure, my point was that both starting point and finishing point
for CT are important, so CT does not introduce delays.

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

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

> two months ago, I was screaming for an event sequence out of
> the handoveer procedure for timing requirement,
> I suggested to define CT triggers and CT deadline based on the
> event sequence

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!

MN>> sure, the starts might be different too, we are trying
to define abstract events, both trigger and deadline without
getting into specific technologies. But we are closely tied
to handovers (at least for scope of CT-seamoby) and so
it makes sense if our events come from handover events.
My question has been whether the group feels we can borrow
these events from Mobile IP handovers (at layer 3)?

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

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.

MN>> what if the newAR receives notification about an iminent
arrival before the MN actually arrives at the newAR. This is
common in cellular! Which category does this fall into?
Proactive? If your proactive includes this, then we are fine.

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

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.

MN>> Well, I said that since Rajeev was dismissing the 
possibility of having the context to handle packets in time.
I agree not all systems/ scnearios could support proactive, but
does that mean we exclude it?

Am I missing the point of your question??

MN>> My question was, don't you think CT should have timing
requirements, so  it introduces zero (proactive) or as little
delay as possible. Don't take me wrong, I don't know enough 
about all the features to believe 100% in zero delay, but it
is a scenario, that should be included.

Regards,
Madjid

---

From: Charlie Perkins <[email-masked]>
Date: Fri, 22 Jun 2001 20:15:15 -0700

Hello Madjid,

> to send and receive L3 packets.

If a node can receive a layer-2 packet, then it could conceivably
receive a layer-3 packet.  And, same for transmission.  This is
separate from whether it's authorized to use the particular layer-3
address.  So, I don't think I see the difference.  Can you explain
more?

> MN>> Please see my earlier email on the 3 cases.

O.K., but can you give me a handle (say, the date)?

> almost equivalent event (say another message that makes packets arrive

Somehow, though, this seems to miss the point.  For reactive,
the context transfer should be reacting to something -- say, the
arrival of a mobile node at the new access network.  Whether
this arrival is determined by the transmission of a layer-3
packet is important, yet necessarily comes after the arrival.
On the other hand, by protocol the only way we can detect
the arrival is by some packet being sent somewhere.
That's why I tried to make the definition in terms of the
_ability_ of the mobile node to send a packet.

I'm curious how a message could be delivered to enable packets,
when the message itself has to be the content of a packet.
This makes me think that we are using different definitions for
what a "packet" is supposed to be.  For me it's a bag of bits,
and can be used at layer 2.

> timing requirements for CT, unless you want to leave it open

I suggest that the starting event is the right way, and that all of the
protocols involved have to be robust enough to work anyway if
something takes longer.  We should just make it work as fast
as we can.

> for CT are important, so CT does not introduce delays.

Yes those are important points in time, but maybe it's enough
to define reactive in terms of whether the _start_ of context
transfer happens before or after the mobile node arrives at the
new access network.

> > it is proactive, if not it is reactive.

If packets arrive for the mobile node before the context is
fully transferred, then the penalty should be lost performance,
not lost packets.  Basing the definitions on "completion"
would mean, for instance, that the previous access router
couldn't really be sure what kind of context transfer was
happening.  After all, the previous access router cannot be
sure of the order of arrival of handover packets vs.
context transfer packets, even if it is sure of the order
in which they were transmitted.  Plus we have to worry
about what happens when CT packets are lost or when
handover control packets are lost, if the system design
admits this possibility.

> these events from Mobile IP handovers (at layer 3)?

In Mobile IP, we defined 4 scenarios.  They were very useful:
- Mobile initiated after departure
- Network initiated after departure
- Mobile initiated before departure
- Network initiated before departure
Context transfer can be sensible in all four of these cases.

> Proactive? If your proactive includes this, then we are fine.

By my understanding, this would be proactive; I am guessing that
the new access router receives context information as well as
the basic indication of the arrival of the mobile node.  But that
amounts to an (important!) optimization.

> does that mean we exclude it?

I definitely propose that we not exclude reactive context transfer.

> is a scenario, that should be included.

I think that context transfer should be optimized for the best
performance in time.  I don't see how you can realistically put
absolute time bounds on the process, though.  What would it
be?  30ms?  300ms?  Shouldn't the same protocol work for
transferring video context as well as audio context (if there needed
to be such a thing)?

Regards,
Charlie P.

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 25 Jun 2001 07:01:17 -0700

> transferring video context as well as audio context (if there needed

I've been in agreement with this since day one.

PatC

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 25 Jun 2001 10:53:37 -0700

Hello Madjid,

> almost equivalent event (say another message that makes packets arrive

Rajeev: We ought to be able to handle IP packets such as an IP packet from the
MN to trigger CT. You don't need any context; only routing needs to work
correctly.

> [snip]

> Am I missing the point of your question??

Rajeev: Perhaps you misunderstood.. If in reactive mode, CT works by fetching
contexts after the MN has arrived at the new AR (and even perhaps after a packet
arrives at the new AR), it does not mean that contexts cannot be there "in
time". Obviously there is predictive CT, and depending on the nature of the
application, even reactive CT could meet the performance requirements.

So, I never dismissed the possibility of CT being undistputably useful :-)  That
is, contexts are there "in time".
[note: this does not mean predictive CT will always accomplish it]

Regards,

-Rajeev

[snip].