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

From: Yingchun Xu <[email-masked]>
Date: Wed, 17 Nov 1999 16:02:03 -0600

I am not against any data buffering for making handoff smooth. Differently
application requires different kind of smooth. Prevently data loss is smooth for
one application and may be bumpy for the other.  Certainly data
buffering/retunneling will help on TCP performance, since reliability is part of
TCP's job. It's like you are doing other people's job.
If you can design a reliable IP protocol, I believe TCP performance will be even
better.

While concerning on TCP, don't forget about RTP (Hey, it's only one character
difference).

--Yingchun.

M Karthik <[email-masked]> on 11/17/99 12:14:43 PM

Please respond to M Karthik <[email-masked]>

Sent by:  M Karthik <[email-masked]>

To:   [email-masked]
cc:    (Yingchun Xu/MW/US/3Com)
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.

        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).

>
>                 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).
>

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

Regards
Karthik <[email-masked]>

>
>
>
> > 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: Lloyd Wood <[email-masked]>
Date: Wed, 17 Nov 1999 22:13:36 +0000

On Wed, 17 Nov 1999, Yingchun Xu wrote:

> I am not against any data buffering for making handoff smooth.
> Differently application requires different kind of smooth.
> Prevently data loss is smooth for one application and may be bumpy
> for the other.  Certainly data buffering/retunneling will help on
> TCP performance, since reliability is part of TCP's job. It's like
> you are doing other people's job.

That is a dangerously wrong assumption that ignores the mechanics of
TCP, and this thread ought to be moved to PILC or to end2end-interest.

L.

is it me, or is this mailing list going to pieces?

> While concerning on TCP, don't forget about RTP (Hey, it's only one character

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

---

From: campbell <[email-masked]>
Date: Thu, 18 Nov 1999 08:00:40 -0500

> > you are doing other people's job.

This is a very valid point. We added a simple "delay device"
in the access network to Cellular IP for sync. That allowed us to get
near opt. TCP
throughput at 1 handoff/sec. So it helps to be helpful and
smart and understand app requirements. You can do two things.
Design for the worst case or be smart. There are pros and
cons.

> TCP, and this thread ought to be moved to PILC or to end2end-interest.

I disagree.

> is it me, or is this mailing list going to pieces?

No its you.

--
Andrew
http://comet.columbia.edu/~campbell