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

From: "Gary Kenward" <[email-masked]>
Date: Thu, 28 Jun 2001 14:42:13 -0400

Rajeev: 
I agree with the logic concerning changing links versus changing handovers.
I am somewhat perplexed about the use of the router discovery protocol
in a handover situations. Adding more over the air round trips to complete 
a handover doesn't sound very seamless to me.

Gary

> -----Original Message-----
> From: Rajeev Koodli [mailto:[email-masked]]
> Sent: Thursday, June 28, 2001 2:10 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: Kulwinder Atwal; '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
> 
> 
> 
> Gary,
> 
> let me cut and paste some text from below.
> 
> > > > > > 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
> > > > > >
> 
> When the MN determines that it has changed its default router, through
> router discovery, it has undergone IP handover. We need to focus on
> IP handover since changing the AR definitively constitutes performing
> CT. On the other hand, if you _only_ change the link, can you be sure
> that you will also change the AR ?
> 
> -Rajeev
> 
> Gary Kenward wrote:
> 
> >
> >
> > Define "handoff".
> >
> > Gary
> >
> > > -----Original Message-----
> > > From: Rajeev Koodli [mailto:[email-masked]]
> > > Sent: Wednesday, June 27, 2001 8:19 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 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.
> > > >
> > > >
> > >
> > > Rajeev: This would work for me.  May be we should ask PatC on
> > > how to proceed
> > > next?
> > >
> > > Regards,
> > >
> > > -Rajeev
> > >
> > >
> > > > >
> > > > >
> > > > > > 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: Thu, 28 Jun 2001 14:07:28 -0700

> a handover doesn't sound very seamless to me.

It is puzzling to me that you would agree with the logic and yet do not
understand what constitutes IP router discovery! It is a procedure that
all IP nodes do as part of bootstrapping their interfaces, including
when they change networks. Simply put, if you changed AR, you would be
doing router discovery. Who is proposing to add more messages over the
air interface?

-Rajeev

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 29 Jun 2001 11:06:04 -0700

> doing router discovery. Who is proposing to add more messages over the

I believe what folks are talking about is that CT can occur before neighbor
discovery is even performed. This is true in the fast MIPv4 draft, and in
the newly advertised BETH draft for MIPv6. We cannot rule these scenarios
out.

PatC