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

From: Kulwinder Atwal <[email-masked]>
Date: Wed, 27 Jun 2001 02:15:03 -0400

> -----Original Message-----
> From: Rajeev Koodli [mailto:[email-masked]]
> Sent: Tuesday, June 26, 2001 7:17 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:
> 
> > >
> > > 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.
> >
> >
> 
> 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

How is this:

Pre-Handoff Context Transfer: The Context Transfer is initiated prior to the
newAR becomes the MN's default router.

Post-Handoff Context Transfer:  The Context Transfer is initiated after the
newAR becomes the MN's default router.

-Kulwinder.

> 
> 
> > 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: Wed, 27 Jun 2001 17:18:37 -0700

> newAR becomes the MN's default router.

Rajeev: This would work for me.  May be we should ask PatC on how to proceed
next?

Regards,

-Rajeev

---

From: Charlie Perkins <[email-masked]>
Date: Thu, 28 Jun 2001 00:13:25 -0700

Hello folks,

> Rajeev: This would work for me.  May be we should ask PatC on how to proceed

From this, I gather that the words "reactive" and "proactive" aren't going to be
used.

Suppose a mobile node shows up, and detects a beacon from the
new access router (not at layer 3).  Then it sends a signal to the router
to initiate handover and context transfer.  System design dictates that
the new router becomes the default router as a consequence of installing
the context features.  Is this a "pre-" or "post-" handover context transfer?
I would say that it happens _at the same time_ as handover, and
furthermore that it is reactive.

Anyway, the definitions chosen should not preclude sensible understanding
of this scenario.

Regards,
Charlie P.

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 28 Jun 2001 06:35:36 -0700

> Rajeev: This would work for me.  May be we should ask PatC on how to proceed

what do folks think about using this terminology? Is this preferred over the
existing terminology in the draft?

PatC

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 28 Jun 2001 10:16:21 -0700

Hello Charlie,

> >From this, I gather that the words "reactive" and "proactive" aren't going to be

Although I didn't think of it, yes.

> furthermore that it is reactive.

This is a good example. What constitutes the new AR becoming the default AR for the
MN is the key point. The above defintions assume IP router discovery mechanisms to
determine whether new AR has become the MN's default AR. Can we conclude for all
link types that you could discover the router via L2 beacons ? It is possible that
you hear the new beacon but the AR has not really changed (e.g., when you change the
AP but the AR is still the same).

> Anyway, the definitions chosen should not preclude sensible understanding

Agreed.

Regards,

-Rajeev