Subject: [seamoby] proactive and reactive CT definitions

From: Rajeev Koodli <[email-masked]>
Date: Wed, 20 Jun 2001 11:48:44 -0700

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: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Thu, 21 Jun 2001 11:54:17 -0500

Hello Rajeev:
Sorry for late response. Please see my inline response.
regards.,
ajoy 

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

Ajoy,

see my replies in-line.

Regards,

-Rajeev

Singh Ajoy-ASINGH1 wrote:

> Hello Rajeev:
> Please find my clarification.
> regards,
> ajoy
>
> 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 ?
>
> Ajoy: In some network, it is easier to receive link layer trigger
> at the target access network much before the completion of link layer and
> network
> layer handoff. The trigger is available when link layer handover
> is in progress. For example, the target trigger can be available
> due to exchange of some link layer message from oldAR to newAR or may be
> from
> MN to newAR.

Rajeev: I guess what you describe could be called a "link-layer triggered
CT".
This is fine on those links where the link-layer trigger is available. Would
go
as far as saying that such a CT is reactive CT ? I would not..

Ajoy:-> The reason I called this reactive because link layer trigger is 
available when handoff is in progress. I guess you can call some 
thing predictive when handover is not yet started. In predictive case 
you are predicting based upon power management or something 
else that handoff is likely to happen but may not eventually happen. 

> I suppose this target trigger can be used to
> initiate so called reactive CT. Please note that there is big
> benefit of doing this.

Rajeev: I agree that there are benefits in using link layer triggers. There
are
also pitfalls. When you transfer context due to a link-layer trigger while
the
old AR is still forwarding packets, the contexts (on the new AR and old AR)
are
out of sync.

Ajoy: -> In what way it is different in case of predictive handover. I hope 
these race conditions if any should be taken care of in protocol design not
in 
requirement. 

> In this case, you know that MN is moving
> to a particular destination network, so you don't end up sending
> Context to unwanted ARs. In case of proactive CT, CT is initiated
> based upon some prediction which may not be always correct.

Rajeev: Well,  proactive need not mean that we don't know where the MN is
going
(and thus we will CT to many ARs). Anyway, let me indicate to you the two
cases
below.

1. We know well in advance the MN is going to new AR. So we do the CT to
that
AR so that all the contexts are in place before the first packet arrives at
new
AR. You could make use of link-layer triggers here.

2. Due to network conditions, the MN looses its link with old AR and shows
up
(after a while) at new AR. You could do CT here after the first packet from
the
MN arrives. Perhaps you could make use of link-layer triggers here as well.

-> I think you got my point. We should rather prefer to use link layer
trigger 
because this will be available before IP packet is received by newAR. Any
context 
transfer based upon this will be faster. So I think we should not eliminate
the 
case where reactive handover can be initiated based upon some link layer 
trigger at newAR. 

We could call 1> proactive or predictive, and 2> reactive.  How's that ?

Ok. 

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

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Thu, 21 Jun 2001 11:55:38 -0500

Hello Rajeev,
See responses below.
I will send another email shortly.

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,

MN>> Cool. However, I think we are revisiting old stuff, without
adding new information.

> We did discuss this issue at length and I think you were in agreement that
MN's

MN>> No, it means the CT is not complete, there might be some context there
already (whether you can use it or not, depends on how you design the CTP,
to 
handle partial context). Also it does not mean that you have not started CT.

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.

MN>> who said it is not working very well?

MN>> That is your own interpretation. 
Nobody claimed that reactive=proactive gone bad (that is only one subset
of reactive). If your network or L2 does not provide good CT triggers, you
can't blame CTP for it. Remember Kulwinder's second point:

CT signaling is different from CT triggers.

MN>> I offerred an interpretation not a text segment from the draft.
If you go back to the archives, you see that this has been mentioned
many times, maybe even by yourself :)

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

MN>> Rajeev, Packet forwarding, buffering, dropping, routing changes
are not CT issues, they are routing and Mobile IP issues.
There was a big discussion on forwarding and buffering
of packets on MIP list, I suggest you take a look at it.
Buffering and forwarding is not the issue CT needs to solve but it is
an issue for a  fast or smooth handover team :)

 We are not working to make L3 HO faster
or with less packet loss, that is MIP fast handover group's 
job. Our job is to make a fast and "reliable CT (a Context
than newAR can beleive in)".
However, if MObile IP defines our mobility scope, then we strive on
doing CT within the time budget that Mobile IP (or its fast handoff
syster) provides, if we make it, it is proactive.
If HO is very fast and/or oldAR or newAR start CT too late, then
CT might not finish before HO completion, then it is reactive, it is
our disclaimer!!

Now I did discussion the possibility of having high priority context
and low priority context, so that the former should be completed
prior to deadline and latter after. This would alleviate the CT
delay issues.

\MN>>

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.

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

MN>> This is a CT trigger question. See my next email.

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

---

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

Rajeev, Ajoy,

This is a prime example of why basing the definition on a CT trigger
is a tricky business when not knowing Mobility protocol, L2 signaling and
the amount of context. We can also get into the discussion of whether
to use L2 source or target trigger, loss of L2 to oldAR or connectivity to
newAR and all sort of things.

Please see below for some other comments,

Regards,
Madjid

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

Ajoy,

see my replies in-line.

Regards,

-Rajeev

> due to exchange of some link layer message from oldAR to newAR or may be

Rajeev: I guess what you describe could be called a "link-layer triggered CT".
This is fine on those links where the link-layer trigger is available. Would go
as far as saying that such a CT is reactive CT ? I would not..

> initiate so called reactive CT. Please note that there is big

Rajeev: I agree that there are benefits in using link layer triggers. There are
also pitfalls. When you transfer context due to a link-layer trigger while the
old AR is still forwarding packets, the contexts (on the new AR and old AR) are
out of sync.

> based upon some prediction which may not be always correct.

Rajeev: Well,  proactive need not mean that we don't know where the MN is going
(and thus we will CT to many ARs). Anyway, let me indicate to you the two cases
below.

MN>> Actually Rajeev, one of the intentions of Proactive was 
to cover the case, in which we don't know where the MN is going. We wanted
to move CT out of the critical path when making Handover decisions
(which AR to handover to, I don't think this problem is solved yet).

1. We know well in advance the MN is going to new AR. So we do the CT to that
AR so that all the contexts are in place before the first packet arrives at new
AR. You could make use of link-layer triggers here.

2. Due to network conditions, the MN looses its link with old AR and shows up
(after a while) at new AR. You could do CT here after the first packet from the
MN arrives. Perhaps you could make use of link-layer triggers here as well.

---

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

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

Kulwinder Atwal wrote:

> > Sent: Wednesday, June 20, 2001 6:16 PM
> > To: Kulwinder Atwal
> > Cc: 'Nakhjiri Madjid-MNAKHJI1'; [email-masked]
> > Hello Kulwinder,
> > Kulwinder Atwal wrote:
> > > I also like the definition as stated in the draft, becuase
> > if the MN has no
> > > real-time traffic, then the AR can choose to conserve
> > scarce bandwidth by
> > > doing Reactive CT with no percievable impact for the End-user.
> > >
> >
> > Rajeev: does this mean that reactive CT is only for the non
> > real-time traffic
> > ?
> >What happens if I cannot do proactive CT and I _do_ have
> > real-time traffic ?
> > Would you not do any CT at all then ?
> >
>
> If we can prioritize context, and provide partial context updates of
> real-time context, then I am fine with your request to change the text.
>
>

Rajeev: May be you would like to bring this up a separate issue ?

Coming back to the point I have raised, I hope you would agree that we have
to consider reactive CT independent of real-time nature of the traffic.
Sometimes, all you have is basic connectivity, and you could use it to
reactively fetch contexts.

MN>> Again I think reactive-ness has more to do with CT-handover 
timing, which is a result of network/ handover design rather than 
the nature of the application traffic.

my 2/100,

Madjid

Regards,

-Rajeev

> - Kulwinder.
>
> >
> > >
> > > If I am doing a file download and loose 60mSec lets say to
> > Reactive CT, I
> > > will not notice as an End-User.
> > >
> >
> > Rajeev: good example. Not sufficient :-)
> >
> > Regards,
> >
> > -Rajeev
> >
> >
> > >
> > > - Kulwinder.
> > >
> > > > From: Nakhjiri Madjid-MNAKHJI1
> > [mailto:[email-masked]]
> > > > Sent: Wednesday, June 20, 2001 5:30 PM
> > > > To: 'Rajeev Koodli'; [email-masked]
> > > > Subject: RE: [seamoby] proactive and reactive CT definitions
> > > >
> > > >
> > > >
> > > >
> > > >  reactive CT, does not always mean that CT cannot start until
> > > > after the MN's
> > > > packets have arrived.
> > > >

---

From: "Gary Kenward" <[email-masked]>
Date: Sat, 23 Jun 2001 17:03:38 -0400

Hmmm. I though I was clear. I only disagree with both halves of the
proposal....
Gary

> From: Pat Calhoun [mailto:[email-masked]]
> Sent: Friday, June 22, 2001 4:51 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: 'Charlie Perkins'; Pat Calhoun; [email-masked]
> On Fri, Jun 22, 2001 at 03:38:50PM -0400, Gary Kenward wrote:
> > Pat:
> >  
> >   The debate has been centered so much around the 
> definition of reactive, 
> > I missed the change in proactive. I agree with Charlie, in 
> no way should 
> > proactive ct be required to end at some particular event. We have a
> > requirement
> > that ct should not delay handover. It is unrealistic to 
> believe that ct will
> > 
> > *never* delay handover and attempting too set a termination 
> limit is just as
> > unrealistic.
> 
> so you are in agreement with the whole change, or just portions of?
> 
> PatC
> 
> > 
> > Gary 
> > 
> > > From: Charlie Perkins [mailto:[email-masked]]
> > > Sent: Friday, June 22, 2001 12:38 AM
> > > To: Pat Calhoun
> > > Hello Pat,
> > > > > So, here is the proposal for revised definitions:
> > > > >
> > > > > Reactive CT: The context transfer process which takes 
> > > place subsequent to the MN
> > > > > establishing a new link with the new AR.
> > > > >
> > > > > Proactive CT: The context transfer process in which the 
> > > contexts are present at
> > > > > the new AR prior to the arrival of MN's packets at the new AR.
> > > 
> > > I would suggest that for Proactive context transfer, we 
> > > should allow for the
> > > possibility that some of the context may still be in transit 
> > > when packets begin
> > > to arrive for the mobile node at the new access router.
> > > 
> > > One other characteristic is that reactive is a "context pull" 
> > > operation,
> > > and proactive is a "context push" operation.  They could 
> still both
> > > use the same protocol message to deliver the context, though.
> > > In other words, as I understand "proactive", the previous access
> > > router predictively sends the context to a new access router
> > > (selected by some unspecified means, presumably initiated by
> > > some radio network controller).  Reactive transfer, on the other
> > > hand, would typically be initiated by the new access router
> > > sending a request for context transfer to the previous access
> > > router.  In many systems that reactive request might actually
> > > be triggered by a message from the mobile node, but the
> > > actual context transfer request would more likely seem to have
> > > emanated from the new access router.
> > > 
> > > Regards,
> > > Charlie P.
> > > 
> > > 
> > > 
>

---

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

I don't like the pull/Push distinction for proactive and
reactive either. It is too restrictive. 
The proactive/ reactive definition were introduced
to deal with timing issues not protocol/messaging issues.

Madjid

-----Original Message-----
From: Pat Calhoun [mailto:[email-masked]]
Sent: Friday, June 22, 2001 3:55 PM
To: Charles E. Perkins
Cc: Gary Kenward; [email-masked]
Subject: Re: [seamoby] proactive and reactive CT definitions

> I'm generally in agreement with your sentiment here, but I sort-of thought
> that some bits had to be able to traverse the medium before a reactive
> context transfer could start.  Your point about possibly asynchronous
> operation, or parallel operation of context transfer and link
establishment,
> is valid I reckon.  And yet the reactive process doesn't just start up
> out of the blue.  Thus, we ought to be able to figure out some words to
> characterize the kind of event that initiates a reactive context transfer.
> 
> Is it possible to use the "push/pull" distinction instead of making
> the definition in terms of a protocol event?  I haven't fully thought
> this through, so I'm not sure...

I don't think so. A pro-active is not bound to a particular direction. In a
target trigger (using the FMIPv4 terminology), it would pull the context,
and
this could occur before the actual handoff is complete. In a source trigger,
the would push the context, and again, it could occur before the handoff is
complete.

So pull/push wouldn't work.

PatC

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Mon, 25 Jun 2001 14:20:53 -0500

-----Original Message-----
From: Charles E. Perkins [mailto:[email-masked]]
Sent: Friday, June 22, 2001 4:36 PM
To: Pat Calhoun
Cc: [email-masked]
Subject: Re: [seamoby] proactive and reactive CT definitions

Hello Pat,

and
> this could occur before the actual handoff is complete.

Do you mean that the new access router could request context from the
old access router before a bit could traverse the air interface?

MN>> That bit doesn't have to be a layer 3 one :)
If it is an L2 target trigger, it can start CT.

>                                                        In a source
trigger,
> the would push the context, and again, it could occur before the handoff
is

This latter case is presumably more common.

> So pull/push wouldn't work.

Too bad.  I agree that if the target trigger context pull is initiated
before the mobile node is connected, the push/pull distinction wouldn't
work.
I'm a little bit surprised that such a case is important, but if it is then
so be it.

MN>> see my previous comment.

That would put us back to defining reactive and proactive in terms of
some recognizable event associated with the mobile node's arrival at
the new access network (or, maybe even "at" the new access router).

MN>>Not necessary, we could make pull/Push subscenarios of reactive and/or
proactive.

Madjid

Regards,
Charlie P.