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 17:40:03 -0500

Hi Charlie, 

Thanks for the valuable insights. Sorry for the delay.
I am responding to your comments in general for now, 
and hopefully get back to you with more details responses
to your statements.

Basically, after giving it some more thought, I like your
definitions more, IF we cover all the holes as I explain:

it seems that you like to see the proactive
or reactive-ness of CT based on a starting trigger, rather
than when CT completes and you want to base the definition
on link establishment rather than handover. 

I agree that handover can be a bit fuzzy, but I want to 
assume that by link establishment you are talking about
a L3 connection ((or Link layer connectivity) between MN and newAR.
If we agree on this, let me go forward. 
 
I can see three cases for how CT can happen in regards to link 
establishment  with the newAR. I intentionally don't bring
 the loss of connectivity with oldAR as a factor here.
(I call the event that starts CT as CT trigger,
it could be explicit or implicit)

1-CT trigger arrives before Handover trigger (what starts the 
handover, it could be at oldAR, at newAR or at MN) and naturally
before link establishment.

2-CT trigger arrives after handover trigger, but before link layer
establishment with newAR.

3-CT trigger arrives after link layer establishment with newAR.

The way I see it, if we want to base the definitions of pro and reactive
on the starting event:

Your Proactive covers 1 and 2. Your reactive covers 3. 
Do we agree? If yes I am ok with this, the reason is
the current draft definition:
Proactive covers only 1 and only if CT completes prior to
packet arrival and reactive covers both 2 and 3 only if CT
completes after packet arrival (it does not cover 2 and 3
if the CT completes before packet arrival). 
So actually the draft definition is not conclusive of all
cases, but your definition does not provide any timing 
requirement (the reason we defined reactive-ness and proactiveness
the way we did).

Note however, that I don't agree that proactive or reactive
should be defined based on inquiry source as you explained in your other
email. 
I don't think proactive=oldAR sends context, 
reactive=newAR sends context request (who sends and who requests 
things is more of a design matter, don't you agree?

We had this discussion for a short while and we all 
decided that who initiates CT should not be the issue.

Regards,
Madjid

---

From: Kulwinder Atwal <[email-masked]>
Date: Sat, 23 Jun 2001 05:55:24 -0400

> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
> Sent: Friday, June 22, 2001 7:02 PM
> To: 'Charles E. Perkins'; Nakhjiri Madjid-MNAKHJI1
> Cc: [email-masked]
> Subject: RE: [seamoby] CT trigger or CT completion? was: proactive and
> re active CT definitions
> 
> 
> 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,
> 
> 
> 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.
> 

I don't know who 'we' are, but as a member of the Design Team I certainly do
not recall 'picking' Handover to mean that we would sequentially hard code
parrallel asynchronous events. 

I do recall argueing strongly against _any_ ordering of events that are not
a direct part of CT and having the text changed to reflect it.  But, I
suppose that the changes did not go far enough.

> MN>> My question was, don't you think CT should have timing
> requirements, so  it introduces zero (proactive) or as little
> delay as possible. 

This is wishful thinking.  It is impossible to guarrantee in a heterogenous
network.

We cannot guarrantee how long something will take, where our mobile device
will be, or the sequence of packet arrival (events).  We can hope for the
best, but we need to plan for the worst (even with proactive). 

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

Even if you are late the end-user will never notice, as long as the packet
is delivered to the MN within the tolerable interpacket jitter of the
Real-Time stream.  

This is the _REAL_ deadline, and it depends on which Real-Time streams you
choose to support.

If the parentAR is heavily loaded with other tasks on a private wireless
network such that each route change message arrives 1 mSec after the CT on a
direct route between newAR and oldAR should proactive CT always fail?

Is dealing with this Proactive 'error' condition not more complicated than
simply removing this restriction?  Will having to deal with this 'error'
condition not introduce more delay?

This protocol will fail to operate in a private wireless network with
requirements 5.4.1 and 5.4.2.  

There is no way to gaurantee the sequence of packet arrival in every type of
wired/wireless network where this protocol may be used.

- Kulwinder.

---

From: "Gary Kenward" <[email-masked]>
Date: Mon, 25 Jun 2001 10:56:50 -0400

The purpose of ct is to enhance handover. If there are no timing
constraints, then it's not worth doing. 

I think, Kulwinder, that you are arguing a matter of degree, and I 
agree with your concerns. But, homogenous, or heterogeneous, it would
seem logical to say that ct should happen as fast as possible, and
that, if it is to actually help handover (the "s" word comes to mind 
here), then it handover should not take longer with ct then without. 

Yeah, I know, "what's a handover" and "when does it end", etc., etc.
We seem to be masters of circular dialectic. It seem to me that when
we began all of this, we shared a common interest in solving the problem.
Now we all seem preoccupied with semantics.

May I suggest that if the ambiguity of "handover" is the issue, then
let's attempt to define it, for I am positive that ct without handover
is like bungee jumping without gravity - you can do it, but what's the 
point?

Just trying to move forward,
Gary

> From: Kulwinder Atwal [mailto:[email-masked]]
> Sent: Saturday, June 23, 2001 5:55 AM
> To: 'Nakhjiri Madjid-MNAKHJI1'; 'Charles E. Perkins'

---

From: "Gary Kenward" <[email-masked]>
Date: Mon, 25 Jun 2001 11:35:38 -0400

> From: Pat Calhoun [mailto:[email-masked]]
> Sent: Sunday, June 24, 2001 11:50 PM
> To: Kulwinder Atwal
> Cc: 'Nakhjiri Madjid-MNAKHJI1'; 'Charles E. Perkins';
> [email-masked]'
> Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive
> and re active CT definitions
> 
> 
*snip*

> > Pre-Connection Context Transfer: The Context Transfer is 
> initiated prior to
> > the newAR recieving a packet directly from the MN. 
> > 
> > Post-Connection Context Transfer:  The Context Transfer is 
> initiated after
> > the newAR recieves a packet directly from the MN.

Ok, so what happened to the packets going in the other direction?

> 
> *this* I like! However, I disagree with your view on handoffs. I would
> like the pre-handoff and post-handoff context transfer. Pre 
> or post first
> packet doesn't make any sense *at all* to me. How can you 
> guarantee, or know,
> when the first packet will be received?!? In all cases that I 
> know of, some
> signalling, either at L2 or L3, is used to register the 
> mobile locally (or 
> some signal strength measurements), but there is always an 
> indication of handoff.

The whole fallacy with the idea of identifying a "concrete" event
to base the *definition* of ct on is that there is no event that can
be "guaranteed" to work in all possible scenarios. For one, we do not
know all possible scenarios.

The idea behind "proactive" and "reactive" was not to define two
different solutions, but to identify two modes of operation. And,
in this, primarily to ensure that some attention was given to 
prophylactic measures. 

As the various requirements resolve, it looks to me that ct still
needs two modes of operation, call them "A" and "B". In "A", 
the network uses whatever information is available to determine
where traffic handovers might take place, and installs context
into those ARs which may be required to handle the traffic. 

Mode "A" includes an intrinsic presumption of having time available,
so the first transfer is probably "static" (or "quasi-static") context -
e.g. context that does not change over time, or context that changes
slowly or with low probability. 

For context that changes quickly, or with high probability, high impact
(e.g. most likely context that changes between packet arrivals), then
there will be a deadline driven transfer of this context. This may or
may not be a wise transfer to attempt, but ctp should provide for it,
if at all possible.

Mode "B" is driven by the assumption that there is little or no time
available before the context is needed at the forwarding AR. Whatever 
scenario one identifies to define the epoch for mode "B", there are
always cases where handover events occur with no warning - e.g. the
network detects the MN in a completely new coverage are, or
the target AR finds "packets in its queue" that must be forwarded.
In mode "B", the network must do whatever it can to get the context
from old AR to the target AR, as quickly as possible. If it takes
seconds to complete the ct, then clearly the handover will not be 
"seamless" (i.e. no degradation of service). For some services, if
it takes 100 ms to re-establish certain feature contexts then the
user will be notice the handover.

There is a proposal for mode "B" to be multiphasic. This is a good
idea, and in fact, the phases appear to be the reverse of the mode
"A" phases. The biggest problem with this proposal is that it's 
premature: it presumes certain timing problems with acquiring the 
context at the oldAR, and delays in transfer. If all the context
can be captured quickly (i.e. in usecs) at the oldAR, and transfer
in one "blob", then a multiphasic solution will slow down ct 
unnecessarily. At this point, the real change in the draft
should be to reflect the requirement that ctp should allow for 
feature contexts to be transferred when it is ready (a configurable
option for the system engineer) 

It matters not what names are given to these modes, what matters
is what changes in the requirements on ctp. 

As for triggers/events: no one trigger/event will ever satisfy everyone,
as every wireless network has different capabilities (and it appears,
this situation will continue).

Just some further sporadic thoughts.

Gary

> 
> 
> > But, really why should we care where the request for CT 
> comes from if we are
> > going to process it just the same?
> > 
> > The only thing that is important is that the requesting 
> entity recieve a
> > packet indicating the success or failure mode of the CT operation.
> 
> ditto.
> 
> PatC
>

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Mon, 25 Jun 2001 15:45:19 -0500

Kulwinder,

You seem to be taking too much stuff out of the context!
Not good in a context transfer discussion :) it would
just add to pollution.

Nobody is engaged in wishful thinking, but not everybody's
scenario is about inter-finger tip handovers on multi-Mpbs
links either. People still are dealing with scenarios where
the speed is over 60 Mph and the link is around 10 kpbs
with a lot of errors and you loose costumers when you drop calls.
So timing is important.
If you look at the archive, I have always said we are
better off removing timing requirements, if cannot come
up with something better than "timely" or "fast" there.
I think Charlie has brought up a lot of good points and
we are making good progress. 

If you read my other emails, I said, I don't care what
 you call reactive or proactive, as long as we cover
all the scenarios, I am fine.

Madjid

-----Original Message-----
From: Kulwinder Atwal [mailto:[email-masked]]
Sent: Saturday, June 23, 2001 4:55 AM
To: 'Nakhjiri Madjid-MNAKHJI1'; 'Charles E. Perkins'
Cc: [email-masked]
Subject: RE: [seamoby] CT trigger or CT completion? was: proactive and
re active CT definitions

- Kulwinder.

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Mon, 25 Jun 2001 16:39:57 -0500

Hello Charlie,

Seems like we have reached an agreement based on our common
interpretation of proactive case, please see below. I added the 3 cases
again, just to make sure.  I cut some of less important text.

The previous email, that you asked about, is also attached, the cases were

, 1-CT trigger arrives before Handover trigger (what starts the 
handover, it could be at oldAR, at newAR or at MN) and naturally
before link establishment.

If you agree that 1 and 2 are proactive and 3 is reactive,
then we are in agreement and you can change the definition
of proactive and reactive based on starting event (link establishment)

I just don't want to have to wait for link establishment to 
start CT.

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

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.

MN>>>> I agree with you. as I said if your proactive covers
the case where handover signaling has started but link is not
established but you still can start CT without waiting for
link establishment, then that is fine.

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.

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

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.

MN>>>> Again see my comments above, I can see the benefit of
using the starting event for the definition over packet arrival
(that we had earlier), as long as you expand the proactive case.

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

MN>> Departure is a bit fuzzy here, does not tell you
what happens to the MN-oldAR or MN-newAR link. 
Also whether Mobile initiates or network is not very
critical for CT. But I see that identifying scenarios
are important, and that is why I asked for event sequences
and some people took it the wrong way and interpreted
that I like to see CT and handover to happen in a sequential
manner.

Context transfer can be sensible in all four of these cases.

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

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.

MN>> Then we are in agreement!!!!

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

I definitely propose that we not exclude reactive context transfer.

> delay as possible. Don't take me wrong, I don't know enough

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

MN>> I agree, absolute numbers don't make sense in a general
requirement document, I have always said that.

Regards,
Madjid N.

Subject: RE: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions
From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
To: "'Charles E. Perkins'" <[email-masked]>, Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Date: Fri, 22 Jun 2001 17:40:03 -0500

Hi Charlie, 

 

Regards,
Madjid

---

From: Kulwinder Atwal <[email-masked]>
Date: Tue, 26 Jun 2001 00:03:02 -0400

> Sent: Monday, June 25, 2001 4:45 PM
> To: 'Kulwinder Atwal'; Nakhjiri Madjid-MNAKHJI1; 'Charles E. Perkins'

> we are making good progress. 

Would it be impossible to wait for both Handover Complete and Context
Transfer Complete before forwarding packets?

It would seem that a good design would need to ensure that both were present
before forwarding packets.

If it is timing that you are concerned with maybe between 2 to 3
Round-Trip-Times would be a better measure of how soon Context Transfer and
Handover need to complete.

- Kulwinder.

---

From: "Gary Kenward" <[email-masked]>
Date: Tue, 26 Jun 2001 11:26:39 -0400

Madjid, Charlie:

Case two below that Madjid has outlined would be reactive, IMCO. 
Borrowing Madjid's numbers for a previous email, with an MN moving at
60 kph, being served by a 10Mpbs stream does not allow any time to
be "proactive" between a possible event indicating the start of handover
(there are many examples) and "link establishment) - the network must
"react" quickly to transfer the context.

This whole discussion seems to be focussed on pinning down reactive ct as a
process triggered by a specific event. To me, the concepts border, if not
lie directly in solution space. Certainly, I find the definition far
too restrictive at this stage.

Gary

> Sent: Monday, June 25, 2001 5:40 PM
> To: 'Charlie Perkins'; Nakhjiri Madjid-MNAKHJI1

---

From: "Gary Kenward" <[email-masked]>
Date: Tue, 26 Jun 2001 11:26:39 -0400

Madjid, Charlie:

Gary

---

From: "Hamid Syed" <[email-masked]>
Date: Thu, 28 Jun 2001 08:03:45 -0400

Hello Charlie,

see my comments below

> From:	Charlie Perkins [SMTP:[email-masked]]
> Sent:	Thursday, June 28, 2001 3:13 AM
> To:	Rajeev Koodli; Kulwinder Atwal
> Cc:	[email-masked]'
> Subject:	Re: FW: [seamoby] CT trigger or CT completion? was:
> proactive and re  active CT definitions
> 
> 
> 
> Hello folks,
> 
> Rajeev Koodli wrote:
> 
> > > How is this:
> > >
> > > Pre-Handoff Context Transfer: The Context Transfer is initiated prior
> to the
> > > newAR becomes the MN's default router.
> > >
> > > Post-Handoff Context Transfer:  The Context Transfer is initiated
> after the
> > > newAR becomes the MN's default router.
> > >
> > > -Kulwinder.
> > >
> > >
> >
> > Rajeev: This would work for me.  May be we should ask PatC on how to
> proceed
> > next?
> 
> From this, I gather that the words "reactive" and "proactive" aren't going
> to be
> used.
> 
> Suppose a mobile node shows up, and detects a beacon from the
> new access router (not at layer 3).  Then it sends a signal to the router
> to initiate handover and context transfer.  System design dictates that
> the new router becomes the default router as a consequence of installing
> the context features.  Is this a "pre-" or "post-" handover context
> transfer?
> I would say that it happens _at the same time_ as handover, and
> furthermore that it is reactive.
	[Syed, Hamid [WDLN2:AN22:EXCH]]  Of course, the scenario you
described here is reactive context transfer where the same event initiated
the context transfer and the handover of the Mobile's flows. But this is one
of the many possible scenarios.

	What about the cases where the events initiating CT and handover are
different? A separate event could be used whenever a mobile is detected by
an AR to initiate the context transfer. This does not guarantee that a
handover of the mobile's flows would happen to the same AR. The default is
still the old AR. I would call it a proactive context transfer. 
> Anyway, the definitions chosen should not preclude sensible understanding
> of this scenario.
> 
> Regards,
> Charlie P.
> 
>

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 28 Jun 2001 06:45:58 -0700

> Define "handoff". 

I believe that what we mean by handoff is the event which an AR receives 
that causes it to start providing service to a mobile. This could be a 
L2 event, either from the oldAR or the MN (IS-41 handoff message and 
802.11 associate, respectively), or via an L3 message (BU).

PatC

---

From: "Gary Kenward" <[email-masked]>
Date: Thu, 28 Jun 2001 09:57:12 -0400

> From: Charlie Perkins [mailto:[email-masked]]

*snip*

> of this scenario

Yes! The nomenclature is not the issue (nomenclature is an issue for the
terminology draft), the issue is whether there is a shared understanding
of what's going on, and whether that concept allows for all the various
scenarios each of us wishes to find solutions for.

Gary

---

From: "Gary Kenward" <[email-masked]>
Date: Thu, 28 Jun 2001 10:00:11 -0400

No, it is not preferred. Not because it is better/worse, but simply
because it is based upon concepts that are at least just as ambiguous
as the previous definitions (which are ambiguous on purpose, btw).

Gary

> Sent: Thursday, June 28, 2001 9:36 AM
> To: Rajeev Koodli
> Cc: Kulwinder Atwal; 'Pat Calhoun'; 'Nakhjiri 
> Madjid-MNAKHJI1'; 'Charles
> E. Perkins'; [email-masked]'
> > > Pre-Handoff Context Transfer: The Context Transfer is 
> initiated prior to the
> > > Post-Handoff Context Transfer:  The Context Transfer is 
> initiated after the
> > Rajeev: This would work for me.  May be we should ask PatC 
> on how to proceed
> > next?
> 
> what do folks think about using this terminology? Is this 
> preferred over the
> existing terminology in the draft?
> 
> PatC
>

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Thu, 28 Jun 2001 11:27:32 -0500

-----Original Message-----
From: Kulwinder Atwal [mailto:[email-masked]]
Sent: Monday, June 25, 2001 11:03 PM
To: 'Nakhjiri Madjid-MNAKHJI1'; Kulwinder Atwal; 'Charles E. Perkins'
Cc: [email-masked]
Subject: RE: [seamoby] CT trigger or CT completion? was: proactive and
re active CT definitions

MN>> It is not impossible, but is it the best we can do?
First of all I am saying we could separate HO and CT from each other.
You agree that L2 HO must be complete (we can get away with
tunneling if L3 HO is not complete) for packet delivery, right?
So you don't always have to wait for L3 HO completion for packet delivery.
 
MN>>Second, some context might not be needed for packet delivery and some
are needed, depending on how you design it.

MN>> Yes, but you said yourself, we don't live in a perfect world.
See my response above.

MN>> RTT is one of the concerns. limiting number of Round trips when you
have long
distances and low bandwidth might not be good enough. 
My goal (I think yours too) is increase the degree of parallelism between
CT and HO.

Madjid

- Kulwinder.

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Thu, 28 Jun 2001 11:34:07 -0500

Gary,
 
Agreed. case 2 is reactive according to the draft and proactive according
to Charlie's definition. I don't see too much difference in how that changes
the concept, but Charlie's definition does make the definitions more clear.

-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Tuesday, June 26, 2001 10:27 AM
To: 'Nakhjiri Madjid-MNAKHJI1'; 'Charlie Perkins'
Cc: [email-masked]
Subject: RE: [seamoby] CT trigger or CT completion? was: proactive and re
active CT definitions

Madjid, Charlie: 

Gary 

> From: Nakhjiri Madjid-MNAKHJI1 [ mailto:[email-masked]
<mailto:[email-masked]> ]

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Thu, 28 Jun 2001 15:22:34 -0500

Hey, I must have missed the point all along, we are
here to write purposely ambiguous requirements that
everybody interprets differently :) The writer of the
most ambiguous definition gets a free T-shirt in London :D

-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Thursday, June 28, 2001 9:00 AM
To: 'Pat Calhoun'
Cc: 'seamoby'
Subject: RE: FW: [seamoby] CT trigger or CT completion? was: proactive

Gary

---

From: "Gary Kenward" <[email-masked]>
Date: Thu, 28 Jun 2001 16:29:14 -0400

No, we can instead defer this subject a write a draft on
"the phases of ct".

Specific requirements are terrific, as long as they do not
exclude solutions that ct is chartered to address. E.g. CT
MUST be performed across wireline links.

Gary

> Sent: Thursday, June 28, 2001 4:23 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Pat Calhoun'
> Cc: 'seamoby'

---

From: "Gary Kenward" <[email-masked]>
Date: Fri, 29 Jun 2001 10:32:46 -0400

Rajeev:

> From: Rajeev Koodli [mailto:[email-masked]]
> Sent: Thursday, June 28, 2001 6:30 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: Pat Calhoun; Kulwinder Atwal; 'Nakhjiri Madjid-MNAKHJI1'; 'Charles
> Gary Kenward wrote:
> > Rajeev:
> > See my previous posting. I agree that you and I have very different
> > pictures. For me, providing seamless handovers means eliminating as
> > much signalling overhead as possible, particularly over the air, and
> > doing as
> >
> 
> I replied to that e-mail. Actually, I am glad that you share 
> these views
> regarding air-interface friendly.
> 
> >
> > much as possible as early as possible. The latter includes 
> reacting as
> > soon
> > as possible to an on-going handover as much as it means being
> > proactive about
> > possible handovers.
> >
> > MN triggers, router discovery, etc. don't fit my goal of 
> providing no
> > degradation to the user service.
> >
> 
> Yet, I don't think you understand what constitutes router discovery.
> This is not something I am proposing new. I guess your definition of
> seamlessness includes not doing router discovery, which is quite
> puzzling.. How does a MN identify its default router and that it is on
> its default router then ? There is an IETF RFC which is implemented in
> numerous nodes. I would have to guess that you would not 
> comply with it.

I guess I don't understand the context of what you speak of. A discovery
algorithm, particularly those described in IETF RFC are designed largely 
to identify static routes through a network (quasi-static, as they also
consider fail-over). To me this has nothing to do with micromobility.

Simply a matter of semantics I would suspect, as certainly one could
interpret
the action of determining the new forwarding path through the access network
to
support a mobile node as "router discovery". But when you quoted IETF RFCs,
I was at a loss - and part of that discovery process are ICMP messages
generated
from the host.

> 
> In any case, the summary is that
> 
> - I am not proposing new messages over the air interface. I would
> appreciate it if you could understand that and stop saying it.

Ok. No new messages (but I am confused about MN generated L3 CT triggers
at this point.
)
> 
> - router discovery provides a good reference point for us for the
> purpose of this discussion. I hope you could focus on that.

No, I don't agree. Other then at a conceptual level, the process of
router discovery has little relationship with mobility. I hope you can
focus on that.

> 
> 
> >
> > This difference of viewpoints is all ok, for we all love 
> diversity in
> > the Internet. But this also means that the definition of CT 
> should not
> > be limited, at very least, not limited so early in the 
> design process,
> > to exclusive trigger events when the potential of alternative
> > approaches has not been explored.
> >
> 
> Well, my argument is that the current defintion is ambiguous and
> insufficient.

Yes, we are all well aware of this. And everyone is focussed on the
debate over this one possible approach to ct. You don't do the design
in a requirements document, but that is what's going on. 

CT is not about triggering off of one possible event, it is about a 
protocol that can be initiated by many different possible events to
support mobility.

You want to get on to detail? Then let's close off the requirements,
and move onto the design. Then we can compare the relative merits of
different approaches, and see if it really makes a difference to CT.

Gary

> -Rajeev
> > > From: Rajeev Koodli [mailto:[email-masked]]
> > > Sent: Thursday, June 28, 2001 2:30 PM
> > > To: Kenward, Gary [WDLN2:AN10:EXCH]
> > > Cc: Pat Calhoun; Kulwinder Atwal; 'Nakhjiri Madjid-MNAKHJI1';
> > 'Charles
> > > Gary Kenward wrote:
> > > > And that "standard router discovery" works for mobile access?
> > >
> > > I don't know what you mean, but, if it is in a standards 
> track RFC,
> > I
> > > "guess" it (router discovery) should work for whatever access. We
> > know
> > > it does and provides a standard reference for us. Given the
> > different
> > > pictures we all have, this is perhaps the best we have as a
> > reference
> > > point.
> > >
> > > -Rajeev
> > >
> > >
> > > >
> > > >
> > > > Gary
> > > >
> > > > > From: Rajeev Koodli [mailto:[email-masked]]
> > > > > Sent: Thursday, June 28, 2001 2:01 PM
> > > > > To: Kenward, Gary [WDLN2:AN10:EXCH]
> > > > > Cc: Pat Calhoun; Kulwinder Atwal; 'Nakhjiri Madjid-MNAKHJI1';
> > > > 'Charles
> > > > > Hello Gary,
> > > > > Gary Kenward wrote:
> > > > > > To expand a bit on my previous question: what defines a
> > "default
> > > > > > router"
> > > > > > in a mobile wireless access network? This is a similar issue
> > to
> > > > > > defining
> > > > > > "what is a handoff or handover".
> > > > > >
> > > > > >
> > > > >
> > > > > Rajeev: There is standard IP router discovery that
> > > enables any node
> > > > to
> > > > > determine its default router. See RFC 2461.
> > > > >
> > > > >
> > > > > > Before everyone starts talking MIP, be reminded that the
> > > > > charter (and
> > > > > > the
> > > > > > problem statement, and the requirements) state that ct
> > > should work
> > > >
> > > > > > with
> > > > > > with different wireless networks and different mobility
> > > > > solutions and
> > > > > > not
> > > > > > just with MIP (if ct is to be an augmentation of MIP, fine,
> > let
> > > > Pat
> > > > > > rewrite
> > > > > > the charter and those of use who need to work on non-MIP ct
> > can
> > > > move
> > > > > > on).
> > > > > >
> > > > >
> > > > > Rajeev: router discovery is independent of MIP.
> > > > >
> > > > > >
> > > > > > Clearly, from the discussion that has transpired, if we
> > > all really
> > > >
> > > > > > believe
> > > > > > that defining an "event" for reactive mode in the 
> requirements
> >
> > > > draft
> > > > > > is key
> > > > > > to making ct work, then we should define what a handover is.
> > As
> > > > > > everyone
> > > > > > knows by now, I do not believe it is required by for the
> > > > requirement
> > > > > > document,
> > > > > > and even more important, I suspect that a general definition
> > of
> > > > > > handover
> > > > > > will take a long time to work out. However, if the wg
> > > believes it
> > > > is
> > > > > > needed,
> > > > > > then let's make the valiant attempt.
> > > > > >
> > > > >
> > > > > Rajeev: using "default AR" as the basis would not need such a
> > > > > defintion.
> > > > >
> > > > > Regards,
> > > > >
> > > > > -Rajeev
> > > > >
> > > > >
> > > > > >
> > > > > > Regards,
> > > > > > Gary
> > > > > >
> > > > > > > From: Rajeev Koodli [mailto:[email-masked]]
> > > > > > > Sent: Wednesday, June 27, 2001 8:28 PM
> > > > > > > To: Pat Calhoun
> > > > > > > Cc: Kulwinder Atwal; 'Nakhjiri Madjid-MNAKHJI1'; 
> 'Charles E.
> >
> > > > > > Perkins';
> > > > > > > [email-masked]'
> > > > > > > Pat Calhoun wrote:
> > > > > > > > On Tue, Jun 26, 2001 at 04:16:37PM -0700, Rajeev
> > > Koodli wrote:
> > > >
> > > > > > > > > > >
> > > > > > > > > > > Rajeev: I guess the point is that you would
> > > do CT either
> > > >
> > > > > > > > > > >
> > > > > > > > > > > 1. before the new AR becomes the MN's default
> > > router, or
> > > >
> > > > > > > > > > > 2. after the new AR becomes the MN's 
> default router
> > > > > > > > > > >
> > > > > > > > > > > Both 1) and 2) are related to handover.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > The point of above text was to indicate that defining
> > > > > > > context transfer to be
> > > > > > > > > independent of handover is perhaps not 
> sensible. Getting
> >
> > > > > > > it to work with
> > > > > > > > > handovers is the challenge we are peddling.
> > > > > > > > > If we all agree on this, may be we should try to
> > > > > close the issue
> > > > > > ?
> > > > > > > >
> > > > > > > > The issue I have is that the current 
> definitions use some
> > > > > > > random packet destined
> > > > > > > > for the mobile as the timing "event". This, im my mind,
> > > > > > > makes no sense whatsoever,
> > > > > > > > because one side (oAR) may not know when the 
> packet shows
> > > > > > > up, and therefore it
> > > > > > > > has no idea whether a reactive or proactive CT is to be
> > > > invoked.
> > > > > > > >
> > > > > > > > FWIW, some CTs will transfer L2 session keys used for
> > > > > > > authentication and
> > > > > > > > encryption, so this is where the first packet doesn't
> > > > > make sense.
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > Rajeev: But the above text (and the text Kulwinder sent
> > > > > > > today) does not say anything
> > > > > > > about the "first" packet. It is based on whether CT is
> > > > > > > initiated when the new AR is
> > > > > > > (not) the default router.
> > > > > > >
> > > > > > > -Rajeev
> > > > > > >
> > > > > > >
> > > > > > > > PatC
> > > > > > > > >
> > > > > > > > > Regards,
> > > > > > > > >
> > > > > > > > > -Rajeev
> > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> > > > >
> > >
> > >
> 
>