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

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Wed, 20 Jun 2001 17:58:26 -0500

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. I suppose this target trigger can be used to 
initiate so called reactive CT. Please note that there is big 
benefit of doing this. 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. 

-----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: Rajeev Koodli <[email-masked]>
Date: Wed, 20 Jun 2001 16:59:59 -0700

Ajoy,

see my replies in-line.

Regards,

-Rajeev

Singh Ajoy-ASINGH1 wrote:

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

> I suppose this target trigger can be used to
> 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.

> In this case, you know that MN is moving

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.

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

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 20 Jun 2001 17:33:16 -0700

in my mind

Reactive Context transfer - MN looses its link with the oldAR and
shows up at the newAR. the MN supplies both the oldCoA. the newAR 
requests the oldAR to transfer context related to the MN. the oldAR 
supplies it. the newAR instantiates the context.... till this 
happens a few packets get dropped. you do the context transfer fast
enough so that the MN does not have to 

1. go through establishing a security association with the access
router again (this could take more than 2 seconds if AAA is used)

2. set up header compression state again... 

3. and etc...

this IS reactive context transfer. basically you are reacting to
the handover.

Vijay