Subject: FW: [seamoby] CT trigger or CT completion? was: proactive and re active CT definitions

From: Kulwinder Atwal <[email-masked]>
Date: Sat, 23 Jun 2001 03:41:53 -0400

-----Original Message-----
From: kalatwal [mailto:[email-masked]]
Sent: Saturday, June 23, 2001 3:10 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

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

As I have said many, many times on the Design Team list these 'timing
requirements' are not necessary, and unworkable in a heterogenous network.  

I fully agree with everything that Charlie has said in his last email.

> 
> MN>> Sure, my point was that both starting point and finishing point
> for CT are important, so CT does not introduce delays.

They are only important if you are unwilling to design a state machine for
the protocol to accommodate an imperfect world.

The packet exchange for context transfer can be the same for proactive and
reactive.  
The only thing that is really different is where the context request comes
from.

With Multi-Phasic Context Transfer there is really no difference between the
Reactive or Proactive packet exchanges other than where the request comes
from.

I believe we should drop the terms Proactive and Reactive since some people
seem to attach them to events in MIP like HandOver.  And, then use HandOver
to unnecessarily constrain the design of CTP. 

I would much rather see a protocol that allowed things to happen as fast as
hardware will allow rather than wait for some artificial protocol event.
The problem with waiting for HO is that it only works well if your network
has been tightly engineered from the beginning.  

This expectation does not hold true for private wireless networks connected
to Ethernet LANs where packet collisions could re-arrange the packet order
of HO and CT.

I would like the terms Proactive and Reactive replaced by packet order
neutral terms:

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.

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.

- Kulwinder.

> Regards,
> Madjid

---

From: Pat Calhoun <[email-masked]>
Date: Sun, 24 Jun 2001 20:50:11 -0700

> the newAR recieves a packet directly from the MN.

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

> packet indicating the success or failure mode of the CT operation.

ditto.

PatC