Subject: Re: [MOBILE-IP] Route Optimization draft comments

From: Mohamed Khalil <[email-masked]>
Date: Wed, 17 Nov 1999 10:26:35 -0600

Hi Yingchun,

> -----Original Message-----
> From: Yingchun Xu [SMTP:[email-masked]]
> Sent: Tuesday, November 16, 1999 4:21 PM
> To:   Khalil, Mohamed [RICH2:IP15:EXCH]
> Cc:   [email-masked]
> Subject:      RE: [MOBILE-IP] Route Optimization draft comments
>
>
>
> Well,  first, let me point out that it would be even worse for delay
> caused TCP
> retransmission since duplicated packets will consume more air link
> resource and
> cause airlink congestion.
>
                [MK>]  Let us divide the problem for simplicity into two
cases:
                case 1: In this case the buffering and forwarding for data
happens before the TCP times out in this case there is no doubt that we
enhance the performance of TCP.
                case 2: the buffering of data already happens but
unfortunately the forwarding of data happens after the TCP times out. In
this case the sender will send some of the packets in the window which are
not acknowledged yet by the receiver. But because of the fact that we have
buffered data the receiver will receive some duplicated data and a lot of
data which might be lost if we didn't buffer the data. The receiver will
acknowledge the last packet which he received and will prevent the sender
from sending the rest of the window which is supposed to be lost if we did
not buffer the data. This will contribute in general in enhancing the
performance of TCP.

                One important benefit of buffering is to disallow
unauthenticated FA from receiving data of the MN before the authentication
phase is completed. This will protect MNs from fraud FAs.

                There are some studies will be conducted by the UTD
(University of Texas in Dallas) to study the effect of this type of
buffering mechanisms on the performance of reliable protocols (eg. TCP).

> So the question is how much delay has been introduced by your "smooth
> handoff"
> scheme. Since you mentioned your "Buffer management"draft,
> I read through it briefly and have following comments:
> 1. the MAH may not work if Agent Discovery procedure is the only mechanism
> for
> FA handoff detection. This is a chicken and egg
> issue. If you dicovery the new FA, you are very likely will lost contact
> with
> your old FA. Then how do you send your buffering request to old FA?
>
> 2. The draft mentioned about using SAH or PFANEH after MAH failure and the
> failure is detected by using time-out. This timeout may cause more delay.
>
> 3. During the transition from MAH to SAH or PFANEH, it seems that quite a
> few
> roundtrip communication happens. This may introduce some delay.
>
> Overall, the "smooth handoff" may not be that smooth and even more bumpy
> for
> delay sensitive traffic such as VOIP traffic.
>
> --Yingchun.
>
                 [MK>]  Mobile IP, Route Optimization  as well as Buffer
Management protocols are protocol designed to fit any wireless technology
In the Buffer Management protocol we gave examples of how the Buffer
Management protocol  is applied in the following generic wireless
technologies which cover most of the wireless technologies exist today (but
not all):

                Type A: we assume that this  wireless technology allows the
MN to detect motion by the help of the wireless network and/or any L2
signals. Also, we assume that the MN has an access to the data channel of
the old subnetwork while the MN is making a handoff. So, it is recommended
for the implementers to use the signal flow of Figure 1 in his
implementation.

                Type B: we assume that this wireless technology allows the
MN to detect motion by the help of the wireless network and/or L2 signals,
but the MN looses access to the data channel of the old subnetwork but it
has been assigned a data channel on the new subnetwork. So, it is
recommended for the implementers to use the signal flow of Figure 2 in his
implementation.

                (Type A and Type B are mobile assisted handoff
technologies.)

                Type C: we assume that the wireless technology does not
provide any help to the MN for motion detection and the MN must use an
external messages such as agent advertisement for motion detection. We
recommend the implementers to use the signal flow of Figure 3 in his
implementation. I think the reason of the confusion is that this figure has
a mistake and it will be corrected in the newer versions.

                If the MN is currently roaming over a network of type A then
it will use the signals flow in figure 1 to handoff to a network of type A,B
or C. The same argument can be applied to networks of type B and C. The
reason we assumed wireless technologies of type A and B because it might be
not efficient to use a periodic agent advertisement for motion detection
since this might lead to inefficient usage of radio channels  and added
delays . How fast the MN can switch from one technology to another
technology?  the answer of this question is outside the scope of this draft.

                [MK>]

                For more information about the implementation you can
Contact  Alberto E. Cerpa at the  Southern California   who impemented a
similar protocol for sun.
>
>
>
> "Mohamed Khalil" <[email-masked]> on 11/16/99 03:18:05 PM
>
> Sent by:  "Mohamed Khalil" <[email-masked]>
>
>
> To:   Yingchun Xu/MW/US/3Com@3Com, [email-masked]
> cc:
> Subject:  RE: [MOBILE-IP] Route Optimization draft comments
>
>
>
>
>
>
> > -----Original Message-----
> > From:   Yingchun Xu [SMTP:[email-masked]]
> > Sent:   Tuesday, November 16, 1999 3:03 PM
> > To:     [email-masked]
> > Subject:     Re: [MOBILE-IP] Route Optimization draft comments
> >
> > Hi, Charles,
> > In the "Route Optimization draft", there is an in-flying traffic
> > retunneling
> > function, which tunnels in-flying  traffic
> >  from old mobility agent to new mobility agent for smooth handoff. I
> > personally
> > feel that the function is not that much
> > useful for the following reasons:
> > 1. If the traffic is delay sensitive such as Voice traffic, I would
> prefer
> > it
> > being dropped than delayed. The retunneling will cause delay.
> >
> > 2. If the traffic is non-delay sensitive, upper layer protocol such as
> TCP
> > will
> > resend it anyway whether is delayed or lost.
> >
>      This will cause a performance degradation for TCP and any other
> reliable protocol if we don't retunnel. I think retunneling the in-flying
> traffic is a useful feature and Route Optimization SHOULD enhance this
> feature by supporting some type of  buffering mechanism to decrease the
> window of data loss. For more information about data buffering you can
> look
> at the "Buffer Management for Mobile IP" draft which has been presented at
> this IETF meeting.
> > Any comments?
> >
> > --Yingchun.
> >
> >
> >
>      MK
>
>      Nortel Networks
>  << File: Internet HTML >>

---

From: M Karthik <[email-masked]>
Date: Wed, 17 Nov 1999 23:44:43 +0530

> not buffer the data. This will contribute in general in enhancing the

        Another advantage we see in buffering is that, TCP at the sender
will soon start to transmit after handoff as soon as the routing gets
estabilished. (More on the why TCP takes time to transmit when Basic Mobile
IP Protocol is used can be seen in Ramon Paper).

> buffering mechanisms on the performance of reliable protocols (eg. TCP).

        Our initial investigation using network simulator (ns2) shows
considerable improvement in TCP throughput.

Regards
Karthik <[email-masked]>

---

From: Lloyd Wood <[email-masked]>
Date: Wed, 17 Nov 1999 18:37:46 +0000

> > not buffer the data. This will contribute in general in enhancing the

You talk of acknowledging the last packet.

Have you considered the effect of your approach on SACK, timestamps,
and RTT estimation?

L.

presumably you're not buffering acks.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>