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

From: "Gary Kenward" <[email-masked]>
Date: Fri, 22 Jun 2001 15:31:44 -0400

Pat:

 I do not. While I understand the general argument, and I actually agree
with it, I see tying reactive CT to the events mentioned as being too
restrictive. 

 To echo Charlie's own arguments: "establishing a link" is a process, not an
event, and the definition proposed below links reactive CT to then end of
that
process. What if someone wants to use the start of the process as the event?
What is someone wants to use an L2 event to initiate a reactive CT that is
coupled but asynchronous to the "link establishment"?

The bottom line is that tying the requirement to a specific event prevents
others from taking a different approach, and ct was supposed to be
applicable to any wireless or wireline network.

Gary

> -----Original Message-----
> From: Pat Calhoun [mailto:[email-masked]]
> Sent: Thursday, June 21, 2001 7:07 PM
> To: Rajeev Koodli
> Cc: Pat Calhoun; Kenward, Gary [WDLN2:AN10:EXCH]; 
> [email-masked];
> [email-masked]
> Subject: Re: [seamoby] proactive and reactive CT definitions
> 
> 
> > I did open an issue, and I proposed the text. See at the 
> bottom of this e-mail.
> > We need to revise it a little bit now.
> 
> right.
> 
> > 
> > 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.
> > 
> > Charlie: would you consider revising it further ?
> 
> and other folks, too, of course :)
> 
> Do folks generally favor such a change?
> 
> PatC
> 
> --------------------------------------------------------------
> -----------
> This email server is running an evaluation copy of the 
> MailShield anti-
> spam software. Please contact your email administrator if you have any
> questions about this message. MailShield product info: 
www.mailshield.com

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 22 Jun 2001 14:01:22 -0700

Hello Gary,

> event, and the definition proposed below links reactive CT to then end of that

It's still coupled to an event associated with link establishment.
Maybe the words need refinement, but the idea might be clear enough.

> others from taking a different approach, and ct was supposed to be applicable
> to any wireless or wireline network.

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

Regards,
Charlie P.

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 22 Jun 2001 13:54:35 -0700

> 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: "Charles E. Perkins" <[email-masked]>
Date: Fri, 22 Jun 2001 14:35:39 -0700

Hello Pat,

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

>                                                        In a source trigger,

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.

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

Regards,
Charlie P.