Subject: RE: [mobile-ip] Extension proposal for FMIPv6 draft

From: Phillip Neumiller <[email-masked]>
Date: Mon, 2 Jul 2001 11:17:55 -0400

Hi James et al,

My only reaction when I read this was WOW and great job BTW!  I am 
really excited about the possibilities of this draft.  I have a
?few? :-) comments on the draft.

1).  In the introduction section 1 sentence (last) did you mean to
     use the word "defend"?  Just seems like a peculiar choice of
     wording although it does seem appropriate.

2).  In section 1, when the "added benefit" of compression state is
     discussed, you may need to be a bit careful with respect to
     soft handover and SDU location.  IF you are assuming that the
     said AR is upstream from the SDU (when an SDU is used), then
     the text is OK for the network side.  However, I was not sure
     if your proposal allowed macro-diversity legs to "travel" 
     through newARs (i.e. concept of active set, etc. done with 
     IP routing).  Typically, a RAKE receiver in the MN would 
     combine these seperate legs passed through seperate ARs.  I 
     know you are going to say "that is too RF specific Phil", but
     really it does not have to be, since the same generalized
     technique could apply to almost any RF technology (with some
     care).

3). When RF links are talked about as being slow, do you mean in the
    Burst speed, the round trip time over the air interface, the
    average throughput under workload conditions or something else?
    I was not sure what exactly was meant here.  You compare wireless
    to wired here and I am not sure whether we have apples and
    apples.

4). When you talk about the "rapid fading" that may occur on radio
    links this is typically engineered out by the RF layer when
    macro-diversity is used, i.e. your MN is communicating with
    multiple base stations so chances are pretty good that not all
    of them will fade at once (except in the case of a shadow fade
    in which case I agree).  The shadow fades will appear as brief
    interruptions of transport. 

5). Also, in WLANs, if the WLAN does not have a RAKE receiver, as
    in most "standard" IEEE 802.11 implementations, fading is also
    a problem in campus and indoor communications environments.  Also,
    shadow fades are even more prevelant indoors than outdoors.  This
    suggests that macro-diverstiy (at the IP level) could be gainfully
    applied over the top of multiple access points to avoid shadow 
    fades that will be prevelant when MNs only communicate with one
    AP (alas this would require IEEE involvement IF you wanted it to
    work with 802.11 type networks) see IEEE TG F activities.

6). Of course as I have mentioned many times, I believe we SHOULD 
    allow SeaMoby Context to be coupled with the HRqst message so that
    the oAR and nAR can decide "intelligently" about admission of the
    mobile (from either perspective or both).

    Also, I have suggested sending the HRqst to the *candidate set* so
    parallelization of this decsion occurs.

7). In the underlying principles section, I am not sure I understand
    what you mean by micro-manage?  IMHO ideally, the MN would be
    "in-the-loop" as far as handover candidates are concerned in most
    cases, since it is the only entity with a complete picture of the
    physical and logical network topology at the instant of handover.

8). I realize the draft is trying to be general purpose, but I don't
    think we can just "hand wave" soft handover away.  

    The paragraph (page 7):

    "... as could happen in a three cell corner junction", is only 
    REALLY applicable to a hard handoff based system, since it is
    actually desirable to have 3 active ARs as opposed to 2 or just
    one.  I would like to see this clarified a bit more.

9). When you say that the "fixed network" is orders of magnitude 
    faster, I get nervous.  If an operator deploys a network they will
    put the minimal amount of bandwidth and AR capacity to handle the
    traffic generated at busy hour to keep their costs down.  So what
    I am saying is that the signalling latency in the access network
    may need to be "slushed" or compensated for in a "soft way" as well
    as the wireless side.  There is that nasty thing called congestion
    that is all-to-frequent in IP networks.  UNLESS your assumption is
    QoS policy managed or reserved signalling bandwidth???

10).I am also really nervous about your discussions about compression
    state.  Compression decompression MUST be done pre- and post- 
    selection/distribution in CDMA networks.  Also, in a VOIP network
    this would likely be done up in the core by the VOIP gateway on
    the fixed side and in the MN on the mobile side.  This ?ERROR? is
    spread throughout the document.  If you are talking about a non
    CODEC compressor, i.e. a link compressor (Lempel Ziv or something)
    applied between the AR and the MN then I can almost see this working.
    However, this will not work well inside the SDU loop either. :-(

11).Poor radio conditions dropping MIP signalling packets CAN and
    most likely WILL be mitigated against by deploying macro-diverstiy 
    in 3G networks.  The paragraph discussing this seems to be discussing
    two orthogonal causes and is really not important to the draft (I would
    remove it).  If you have poor radio conditions (that aren't handled
    by the radios) you no longer have a viable product and you are not
    in business long.

12). In figure 1. should the AR on the right be nAR?

13). In the requirements section.  An L2 trigger at the AR is stated 
     as a requirement. This is used in the "network directed" handover
     scenario I guess.  Can we generalize to mobile and network directed
     handover scenarios?  It seems to me that this trigger is ultimately
     dependent upon the mobile anyway.

14). It seems that nAR can only be "known" by the mobile so indeed this
     trigger is dependent on the mobile giving oAR the nAR IP address.
     What might be a better approach is for the MN to perodically 
     send oAR a list of "candidate" nARs with their RSSI data (plus 
     possibly other goodies) then the oAR can do a SeaMoby CT querry
     to get layer 3 info and make a better informed decsion about the HO.

15). The MN l2 address seems competely redundant in the L2 handover start
     since link addressing is already established in order to communicate
     between the MN and the oAR to begin with.  All you need is an 
     event notifier right?

16). In section 3.2 you state "if latency sensitive transfer is underway".
     I would remove this conditional.  If its a better way, just do it
     that way all the time!  I see no reason to distinguish in this
instance.

17). NOTE: No consideration of multi-cast routing.

18). NOTE: No consideration of how SCTP multi-homing could dovetail
beatifully
     with this approch.

19). I got confused in the two +three party handover stuff.  I am wondering
     why there needs to be a distinction like this.  NOTE: I need to read
     this long hairy section more carefully.

20). The two/three party stuff reminded me of why timers like TADD and 
     TDROP are part of the soft handover spec.  It would seem that more
     careful attention needs to be applied to link "add" timers and 
     link "drop" parameters to get the hysteresis out of the system.  A
     statement like "waiting until the probability of ping-pong is low" 
     seems to hand wave this problem away.  I am not convinced that we
     can wave ping-pong away so easily in this draft.

21). BTW, why doesn't this proposal support multiple active link layers?
     Many RF XCVRs of the future (particularly MANETs and hybrids)will
     have this support implicitly.  Also, 3GPP, 3GPP2 (popular targets
     for MIP related work :-)) have this capability.

22). In section 3.5
     I would say that the ITU bound on latency and gaps is no longer
     applicable to this proposal.  What is really important is the end-to
     end latency reduction made possible for each MN in such a network
     under busy hour conditions and the fact that there are NO network
     introduced packet losses, hurray!!!

23). Regarding Handover Smoothing IMHO
     Buffering will not work.  Bi-casting is the ONLY answer for real
     time latency sensitive traffic.  Buffering introduces latency and
     forces packets to grow old.  It is not appropriate for this proposal.

24). Since the ARs are indeed routers, multi-cast routing should be 
     considered as a long term goal to replace temporary source 
     routed tunnels -OR- alternatively, the tunnels can be "learned" and
     compressed bundles of traffic can be shuttled between the ARs
     that have "learned" the traffic patterns.  This is a very Mesh-like
     thing to do.  Also, in this case, using point-to-point physical links
     between heavy HO traffic AR pairs (those involved in lots of handover 
     with each other) can help the physical network topology match the
     logical and aid greatly with QoS on the back haul (usually a big
     expense in cellular type systems).

25). Thanks for the plug in the acknowledgements.  I would prefer that
     you reference the following if you could:
[x]  Phillip D. Neumiller, Peter L. Lei, and Michael L. Needham, "Open
     Base Station Transport (OBAST) Architecture, ACM SIGMOBLE Mobile
     Computing and Communication Review", Vol. 4, No. 3, July 2000.

I really LIKE this draft.  I will probably have more comments when I
get some more time.

Thanks,

Phillip Neumiller
Mesh Networks, Inc.

---

From: James Kempf <[email-masked]>
Date: Mon, 2 Jul 2001 23:11:04 -0700

Hi Phil,

>?few? :-) comments on the draft.

Thanx. We look forward to any further comments. Replies to the existing ones below.

>     wording although it does seem appropriate.

I believe this is the usual terminology in IPv6. A host that uses IP Address Autoconfig
must defend the address by responding to other claims on it.

>     technique could apply to almost any RF technology (with some

The draft is not primarily about radio access networks, though I think the technique
could be used in radio access networks (but that is the subject of further work). 
Therefore, it is not anticipated that SDU functionality will be involved at all, at
least initially.

With regard to header compression, there is a mismatch between current header compression
technology, being pursued in ROHC, and MIPv6. The ROHC group has been designing
for IPv4 where there is no change in the over the air header after handover, because the
FA strips off the tunnel header with CoA (ignoring route optimization for the moment). In 
MIPv6, co-located CoA is standard, so the header changes upon handover, which means the
compressor needs to restart, reducing the bandwidth for real-time traffic. 

The mechanism described in the draft does not require the header to change since the CoA 
doesn't change. The lack of need to restart the header compressor is a serendipitous side
effect. There are a couple other such side effects that fall out of this design, which
were not mentioned in the draft but that I hope will show up in the list discussion.

>    to wired here and I am not sure whether we have apples and

We are talking about expected user data performance for RTT over the air interface,
so the latter of the three you mention. 

>    interruptions of transport. 

Right, typically L3 won't see rapid fading directly, but rather it would see a reduction
in throughput as L2 compensated by using retransmits (for link protocols that
do not support macrodiversity) or perhaps even no effect (for link protocols that
do support macrodiversity). In a hard handover situation, however, rapid fade would
even show up for macrodiversity supported protocols, since most such protocols
would require breaking off the soft handover legs and restarting in the new RAN.

>    work with 802.11 type networks) see IEEE TG F activities.

The problem with 802.11 in particular is that it allows a mobile to be associated with
only one access point at a time, as I understand it. I agree that it would be
nice to be able to do macrodiversity at the IP layer, but I think it would take
a major change in the 802.11 protocol. If you have been involved in 802.11, you
would be in better position to say whether or not it IEEE would be interested
in adding this mode (maybe a third mode, in addition to ad-hoc and infrastructure?).

>    parallelization of this decsion occurs.

Agreed. There are synchronization issues if Seamoby context transfer and handover are
not tightly coupled.

>    physical and logical network topology at the instant of handover.

The difficulty is that, unless signalling channels are used, traffic over the air at L3 to
determine a handover candidate at the time the mobile and the network determine at L2
that a handover is necessary increases the latency at L3. Anything at L3 that is layered
on top of the minimal amount needed for L2 handover will increase handover latency,
unless it can be efficiently done on a parallel channel. 

As a consequence, the draft favors a negotiation between the mobile node and the
network ahead of time in which the mobile node's preferences (more probably the user's
preferences) for access points are expressed and the network then honors those
when performing handover. For this to be possible, the ARs need to know what handover
candidates are in their area, which is where the Seamoby handover candidate
discovery protocol would come in.

If the mobile node has a second radio interface, an alternative is for the mobile node
to monitor the second interface and initiate a standard FMIPv6 handover to that interface 
when it sees that an access point has appeared. In this case, BETH isn't needed because
the MN can set up the second interface in parallel and quickly switch the real time stream
(by sending a BU to the sender) when the interface is completely up, the HA has been
informed, etc.

>    one.  I would like to see this clarified a bit more.

As mentioned above, I agree that soft handover is important. I can qualify this
sentence to mention hard handover, but I think it would probably be better to
keep this draft confined to the general case, and explore implications for
specific radio protocols in other drafts (like the "IP on xxx Link Layer" draft
that come by now and then).

>    QoS policy managed or reserved signalling bandwidth???

Well, I'm taking 9.6 kbps as a figure of merit for the air interface, and even
if the access point (aka BTS) is connected back into the network (aka BSC) with
a T1 line, it's more than an order of magnitude faster. Of course, the T1 is
handling the aggregated traffic from however many mobile are in the cell.

On the other hand, I agree that the operator will deploy the minimal mount of bandwidth
to keep costs down. But I think they will need to engineer the wired side so that
it has enough capacity, and it is easier to add wired capacity than to add air
capacity. Adding wired capacity means simply stringing another wire or leasing
another fixed microwave link. Adding wireless capacity means to redesign the
cell layout to reduce cell size.

>    However, this will not work well inside the SDU loop either. :-(

The draft is just talking about header compression over the air, like the kind proposed by ROHC.
Actually, wCDMA has a hook in L2 for header compression. You are right about
voice compression, however.

>    by the radios) you no longer have a viable product and you are not

OK.

>12). In figure 1. should the AR on the right be nAR?

Yes, thanx.

>     dependent upon the mobile anyway.

Yes, in order for L2 handover to work, the mobile must be involved, but a
trigger is not necessary on the mobile for the L3 signalling involved in BETH.
It is necessary, for example, in FMIPv6 mobile initiated handover for L3 signalling.

>     to get layer 3 info and make a better informed decsion about the HO.

That is one possibile way the oAR could get the candidate handover nARs. 
As I mentioned, the L2 negotiation involved in handover is not addressed
by the draft. 

>     between the MN and the oAR to begin with.  All you need is an 

The idea is the AR needs some indication of which MN to begin the handover for.

>     that way all the time!  I see no reason to distinguish in this

The issue is that the mobile node will at some point want to initiate the CoA change.
The BET from aAR actually constitutes a triangle route, and at some point it
may get extended enough that the MN should change to the new subnet. An opportune
time is when there is no real-time traffic underway.

>17). NOTE: No consideration of multi-cast routing.

From the home network or the local subnet? Home network multi-cast is covered by 
standard Mobile IP. As for the local subnet, because the tunnel is from aAR, any
changes in multicast routing would apply in that subnet. The MN would not get any
traffic through the local AR except as detunneled from aAR. 

Depending on how location based services are set up, this may be a problem.

It does require some more thought.

>18). NOTE: No consideration of how SCTP multi-homing could dovetail

???? My understanding is that SCTP allows multiple streams but only between two
IP addresses. Did you have this in mind for macrodiversity? 

>     this long hairy section more carefully.

The two are somewhat different. Basically, when a BET has already been placed,
you need a way to move the wireless end from oAR to nAR. This is somewhat
different from setting it up in the first place.

>     can wave ping-pong away so easily in this draft.

I agree that there may need to be some timers to take care of ping-pong (with
all due respect to Kulwinder). If you look in the handover smoothing section,
it talks about maintaining a sliding buffer on oAR until the probability of
a ping-pong has decreased low enough. I suspect a timer would be needed there.

>     for MIP related work :-)) have this capability.

I'm not sure I understand what you mean. Do you mean on the mobile? Or through
the access router with the mobile running a software defined radio?

>     introduced packet losses, hurray!!!

The ITU bound is important in so far as it provides a number to guide the engineering.
Without this, one could say that the 100-300 ms latency introduced at L3 by FMIPv6
is acceptable. The draft takes the position that any introduced L3 latency is unacceptable
because L2  latency is unavoidable and depending on radio conditions, the combined
L2 and L3 latency could exceed this bound and reduce the quality of the call.

>     forces packets to grow old.  It is not appropriate for this proposal.

Both bi-casting and buffering have their drawbacks. Jitter on the wired link can
cause duplicate packets or dropouts on nAR with bi-casting. Buffering clogs the
radio channel after handover unless it is restricted to the smallest possible window. By combining
the two (with appropriate L2 engineering) handover can be optimized to reduce 
the probability of duplicates and drop outs. The draft recommends a small buffer
on nAR that just buffers radio frames during the progress of the L2 handover.

>     expense in cellular type systems).

I'm not so sure about multicast, since it would require subscribing to a
group address and managing that might be difficult, but I agree there
are lots of alternatives for traffic engineering.

For example, one is setting up MPLS LSPs between heavily used access routers, and
switching the traffic through the LSPs instead of IP tunnels. 

>     Computing and Communication Review", Vol. 4, No. 3, July 2000.

Sure, be happy to put it it. I should also probably look it up, sounds
like an interesting article.

>I really LIKE this draft.  I will probably have more comments when I

Great, thanx.

		jak