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

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Wed, 20 Jun 2001 16:30:06 -0500

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

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.
 
For reactive, CT can happens simultaneous as Handover signaling
but it might not finish when handover signaling is complete.

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.

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.

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 15:10:32 -0700

Hello Madjid,

> but it seems that is the going trend.

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

>  reactive CT, does not always mean that CT cannot start until after the MN's

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!

> but it might not finish when handover signaling is complete.

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

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

> it does not mean completion of handover signaling and packet routing

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