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

From: George Tsirtsis <[email-masked]>
Date: Tue, 24 Jul 2001 08:07:33 -0400

-----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: Wed, 25 Jul 2001 15:59:36 -0700

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

---

From: Michael Thomas <[email-masked]>
Date: Wed, 25 Jul 2001 16:51:54 -0700 (PDT)

> synchronization issue as well.

As a follow up to my previous comment, I believe
that regardless of whether you allow for bicasting
or not, context transfer of header compression
state should be viewed as a fork operation rather
than a move operation. This allows for race
conditions where MN still sees old-AR packets in
the movement window to be processed correctly.
When it eventually gets to new-AR, new packets to
MN will just look like there were a drop or two
which the new context should be able to recover
from.

		Mike

---

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

> which the new context should be able to recover

We have specified the necessary extensions to address the problem in
draft-koodli-seamoby-hc-relocate-01.txt. Please have a look and we will be happy to
hear your comments.

Regards,

-Rajeev