Subject: RE: [mobile-ip] Handover Smoothing - What to Do?

From: "Gary Kenward" <[email-masked]>
Date: Thu, 26 Jul 2001 10:47:02 -0400

Rajeev:

  Is one answer that the old AR could send uncompressed packets
to the new AR, and the new AR would then compress the packets or
not, depending on whether it had the context (there is a an case
to be made here for proactive ct ;^}). Depending on what was actually
sent over the air, this could create a tricky problem to solve
at the MN, as it may need to process the two streams before it could
even attempt duplicate removal, and this would require two compression
state machines, buffers, etc., etc. Not nice.

  One way of looking at this scenario is that the IP stream is being
handed over in a smooth/fast/seamless manner, but two over the air
links have to be used in a make before break scenario to accomplish this.

Gary

> -----Original Message-----
> From: Rajeev Koodli [mailto:[email-masked]]
> Sent: July 25, 2001 19:00
> To: [email-masked]
> Subject: Re: [mobile-ip] Handover Smoothing - What to Do?
> 
> 
> Hello folks,
> 
> I would like to add that there are issues surrounding header 
> compression as
> well. Note that the context resides on the old-AR. What type 
> of packet does it
> bicast ? compressed or uncompressed packet ? If it is 
> uncompressed, it is not
> useful without the new-AR having the compression context.  On 
> the other hand,
> if the new-AR has to possess the context *simultaneously*, 
> this adds a new
> dimension to header compression: Many-to-One header 
> compression! If the old-AR
> sends compressed packets to the new-AR, how does the latter 
> handle them ?
> Also, since the MN is not bicasting in the uplink, the uplink 
> context is
> current only on the old-AR even if the new-AR has the 
> context. So, there is a
> synchronization issue as well.
> 
> Regards,
> 
> -Rajeev
> 
> 
> George Tsirtsis wrote:
> 
> > -----Original Message-----
> > From: Karim El-Malki (ERA) [mailto:[email-masked]]
> > Sent: Tuesday, July 24, 2001 10:53 AM
> > To: [email-masked]'; [email-masked]
> > Subject: RE: [mobile-ip] Handover Smoothing - What to Do?
> >
> > Hello Raj and James
> >
> > ...
> >
> > >I would recommend removing it and focusing on smoothing
> > > of handoffs in a separate I-D. Handoff smoothing can also 
> be achieved
> > > by buffering. So why recommend only bicasting as the 
> mechanism for the
> > > desired effect? I do not believe there has been any real 
> consensus of
> > > going one way vs the other.
> > >
> >
> > There has been consensus among the design team members and up to now
> > we have not received negative comments on the low latency 
> draft nor during
> > the IETF presentations. I would be happy to consider buffering as an
> > alternative and eventually add it into the draft if the 
> authors/WG want
> > this,
> > but all the methods must satisfy the requirement of 
> eliminating the period
> > of
> > service disruption due to L3 handoff independently of the L2
> > characteristics.
> > Without this IMO the draft would not serve its purpose.
> >
> > GT> This was discussed in (I think) much greater length in 
> the FMIPv6 design
> > team and enough doubts were raised to exclude bicasting 
> from the FMIPv6 spec
> > and encourage its proponents to publish the idea as a 
> separate document,
> > which they did...well done :). The main argument against 
> bicasting was
> > regarding its possible  effects on TCP. Bicasting would 
> duplicate TCP ACKS
> > (along with everything else) and as we know 3 dupacks result in TCP
> > shrinking its window...dupacks occur naturally by TCP as a 
> result of the
> > network loosing or reordering packets and the chance of 3 
> dupacks in a row
> > is not very high. We thought that bicasting may increase 
> the chance of 3
> > dupacks and thus impact TCP performance.
> >
> >
> 
> > Note that there has been work towards eliminating this well 
> known problem
> > and Karim can point the list to this work since I do not 
> remember that draft
> > name. Nevertheless, the FMIPv6 team decided that bicasting 
> has experimental
> > nature and the TCP fix was at the time a draft at 
> v00...early days => not
> > enough practical experiance or understanding of what a 
> possiby wide spread
> > use of bicasting do to TCP. For all the above we thought 
> that bicasting
> > should be discussed as a separate item and the FMIPv6 spec 
> should not be
> > dependant on it. The fact that the FMIPv4 team did not take the same
> > decision always concerned me a bit...
> >
> > IMO smoothing (bicasting and/or buffering) should be 
> separate specs from the
> > FMIPv4/v6 not only because of the uncertainty regarding 
> bicasting but also
> > because (again IMO) smooth handoffs may be achieved at the 
> implementation
> > level and without protocol support. That is not to say that 
> protocol work
> > may not help and should not be done...but only to indicate 
> that "smooth
> > handoff" work should be separate from the FMIP work. In fact, smooth
> > handoffs could be viewed as optional extensions to the FMIP specs.
> >
> > Thanks
> > George
> 
>

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 26 Jul 2001 10:19:18 -0700

Gary,

Gary Kenward wrote:

> to be made here for proactive ct ;^}).

This is exactly what said below! If the new-AR transmits uncompressed
packet, that's not good for spectral efficiency. In order to transmit
compressed packets, it needs context. However, that is not the same as
the context present at old-AR and hence the MN needs to have the ability
to sync up with both the contexts.
This Many-to-One HC is complicated. The case for moving the context is
relatively easier (where you have a single, active  context on the
network side).

> Depending on what was actually

Agreed.

> links have to be used in a make before break scenario to accomplish

Sounds unnecessary, especially for implementing FMIPv6. Bicasting must
not be part of FMIPv6.

Regards,

-Rajeev

---

From: Michael Thomas <[email-masked]>
Date: Thu, 26 Jul 2001 08:10:25 -0700 (PDT)

> state machines, buffers, etc., etc. Not nice.

   It may not be nice, but I believe it comes with the
   territory. The alternative is to miss packets during
   the transition that you might have otherwise been 
   able to recover. For mobile initiated
   break-before-make scenarios, you obviously
   don't want to allow any otherwise valid packets
   to be dropped making the situation worse.

		 Mike