Subject: [MOBILE-IP] Route Optimization draft comments

From: [email-masked]
Date: Mon, 15 Nov 1999 15:59:47 -0600

[For those of you receiving this for a second time, I apologize.  It was pointed
out to me that I used an obsolete mailing list.  I've reset this email using the
latest list.]

Charlie, Dave - Upon learning that the Route optimization draft
(draft-ietf-mobileip-optim-08.txt) was being put to last call, I've reviewed it
and have a few comments/concerns.  I've not been involved in the history of this
draft, so please forgive me if these issues have already been raised and/or
resolved.

The first issue is the number of different methods for updating binding caches
during a registration.  The draft discusses three means:  (1) The MN sending a
binding warning extension during the registration request, (2) The MN sending a
Previous FA Notification extension during the registration request, and (3) the
MN sending binding update messges if it fails to get a binding ack from the FA
after sending the Previous FA Notification extension.

I believe these methods are overkill and should be reduced to just the binding
warning extension (if even that).  I also believe the HA should be required to
send binding updates when it detects a change in the FA assignment for a MN.
Here's the rational:  Only the HA can send the initial Binding Update message to
a node.  It may be in response to a Binding Warning Message/Extension, a Binding
Request, or done on its own, but the HA is the only point where the initial
Binding Update messages originate.  Thus, it knows the full set of all nodes
that may be using a binding cache entry for routing packets.  The HA can also
determine from the Registration Request message that a MN is changing FAs.
Since I believe there is no reason why one would want to leave a node pointing
to an old FA (please correct me if I'm wrong), the HA is the perfect point
during a registration to automatically update all binding caches to all nodes
via the Binding update messsage.  The HA also knows the old FA, so it could send
the old FA a small lifetime (and the full lifetime to the other nodes).  This
would ensure that packets in transit to the old FA would get to the new FA and
would alleviate all the old FA issues related to requiring special tunnels,
binding ACKs and data coming before the  Registration Reply, required MN/FA
security associations, etc.  It would also simplify the MN processing, as (a) it
would not need to maintain a list of nodes it requested binding updates for, (b)
it would not need to worry about Previous FA Notification extension processing
nor binding update messges for the ack failure legs discussed above, and (c) it
would not require a MN/FA security association (which will be painful to
maintain until a standard dynamic key assignment process is adopted).

I would propose making the HA required to keep track of all nodes it sends a
binding update to and require that the HA send a BInding Update to those nodes
and the old FA whenever a MN roams to a new FA.

A second issue is how to handle binding updates for non-routable IP address
assignments.  The HA can not send binding updates for MNs that are assigned non
routable IPaddresses, regardless of the Privacy bit setting.  All packets must
be tunneled throught the HA to the FA.  I believe you want to add this statement
to the draft.

A third issue relates to correspondant nodes tunneling data to the FA instead of
the HA.  If the correspondant node uses GRE, that node must not try to use
sequence numbers.  Since the FA can get data from any number of nodes (as the HA
or MN may initiate the binding update without telling the FA), the FA would need
to setup a sequence number history for each node that tunnels it data.  This is
not reasonable.  Thus, some words are required to discuss what portions of the
tunneling protocols are not allowed.  [I did not review the other options, but
remembered that GRE could pose a problem.]

The last item is minor.  In sections 8 and 8.1, you mention  "Previous FA
Notification messages".  Shouldn't those really be extensions instead of
messages?

Thanks,

Karl Freter
Manager, Wireless System Architecture Group
3Com
847 222 2268
[email-masked]

---

From: Mohamed Khalil <[email-masked]>
Date: Tue, 16 Nov 1999 15:18:05 -0600

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

---

From: Yingchun Xu <[email-masked]>
Date: Tue, 16 Nov 1999 16:20:40 -0600

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.

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.

"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

     MK

     Nortel Networks

---

From: Yingchun Xu <[email-masked]>
Date: Wed, 17 Nov 1999 14:38:22 -0600

Unfortunately, the current and the coming cdma2000 network will not support type
A detection.

--Yingchun.

Mohamed Khalil <[email-masked]> on 11/17/99 10:26:35 AM

Please respond to Mohamed Khalil <[email-masked]>

Sent by:  Mohamed Khalil <[email-masked]>

To:   [email-masked]
cc:    (Yingchun Xu/MW/US/3Com)
Subject:  Re: [MOBILE-IP] Route Optimization draft comments

Hi Yingchun,

> From: Yingchun Xu [SMTP:[email-masked]]
> Sent: Tuesday, November 16, 1999 4:21 PM
> To:   Khalil, Mohamed [RICH2:IP15:EXCH]
> Cc:   [email-masked]
                [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).

> delay sensitive traffic such as VOIP traffic.
                 [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.
>  << File: Internet HTML >>