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

From: Kulwinder Atwal <[email-masked]>
Date: Mon, 25 Jun 2001 21:59:17 -0400

> -----Original Message-----
> From: Rajeev Koodli [mailto:[email-masked]]
> Sent: Monday, June 25, 2001 2:20 PM
> To: Kulwinder Atwal
> Cc: 'Pat Calhoun'; 'Nakhjiri Madjid-MNAKHJI1'; 'Charles E. Perkins';
> [email-masked]'
> Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive
> and re active CT definitions
> 
> 
> Kulwinder Atwal wrote:
> 
> > > >
> > > > 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.
> >
> 
> Rajeev: I like this classification as well.
> 
> > >
> > > *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?!?
> >
> > I can't.  How early to do Pre-Connection Context Transfer 
> to get seamless
> > transfer is implementation specific.
> >
> > The viewpoint is the newAR.  Either the newAR is notified 
> for a need to CT
> > from oldAR, or MN.
> > The difference is on what interface the newAR is notified.
> >
> >
> 
> Rajeev: I guess the point is that you would do CT either
> 
> 1. before the new AR becomes the MN's default router, or
> 2. after the new AR becomes the MN's default router
> 
> Both 1) and 2) are related to handover.

Yes, but handover is pretty vague. Like Gary said, is the start, exact
middle, or end of handover, or some special protocol event in the middle.
In a collision based wired, or a wireless network we can't be certain which
protocol packet will arrive first.

Also, we all seem to agree that if pre-connection Context Transfer takes too
long due to the uncertain nature of wireless (End-user drives through a
tunnel), it is very likely that several post-connection events will pass
before the transfer is complete.

So, we may start with the best of intentions with the intent of being early
enough to not affect the user experience, but events may overtake us such
that we find ourselves out of time.

So, what do we do at that point in time?  

A particular technology may find it advantageous to do post-connection, if
the data is available, even after the user has experienced a distruption,
becuase the connection setup time will be longer than the post-connection
Context Transfer time.

An other technology may find it advantageous to re-establish new context,
because the Context Transfer time (Round-Trip Times) are greater than new
connection setup.

- Kulwinder. 

> 
> Regards,
> 
> -Rajeev
> 
> 
> > It is up to the implementor to take into account particular 
> network and
> > inter-network characteristics and real-time flow 
> requirements to determine
> > how early Pre-Connection Context Transfer needs to be done 
> to guarrantee
> > seamless.
> >
> > - Kulwinder.
> >
> > > 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.
> > >
> > >
> > > > 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.
> > >
> > > ditto.
> > >
> > > PatC
> > >
>

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 26 Jun 2001 16:16:37 -0700

> > Both 1) and 2) are related to handover.

The point of above text was to indicate that defining context transfer to be
independent of handover is perhaps not sensible. Getting it to work with
handovers is the challenge we are peddling.
If we all agree on this, may be we should try to close the issue ?

Regards,

-Rajeev

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 26 Jun 2001 16:17:03 -0700

> If we all agree on this, may be we should try to close the issue ?

The issue I have is that the current definitions use some random packet destined
for the mobile as the timing "event". This, im my mind, makes no sense whatsoever,
because one side (oAR) may not know when the packet shows up, and therefore it
has no idea whether a reactive or proactive CT is to be invoked.

FWIW, some CTs will transfer L2 session keys used for authentication and 
encryption, so this is where the first packet doesn't make sense.

PatC

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 27 Jun 2001 17:27:34 -0700

> encryption, so this is where the first packet doesn't make sense.

Rajeev: But the above text (and the text Kulwinder sent today) does not say anything
about the "first" packet. It is based on whether CT is initiated when the new AR is
(not) the default router.

-Rajeev