Subject: [mobile-ip] RE: any ideas for this problem?

From: "Ed Remmell" <[email-masked]>
Date: Mon, 21 Apr 2003 12:37:32 -0700

Jari -

Executive Summary:
Gabriel's concerns about 802.11 link speed switching appear to be
unwarranted - 802.11 MAC/PHYS is responsible for ensuring that unicast
packets are received correctly by the peer, and if/when they aren't (since
they must by ACK'ed by the peer's 802.11 MAC), they are retransmitted, until
finally (w/ regards to Gabriel's scenario) the access point decides to
downshift the link speed used with that specific MN so that they are
received correctly. Receipt of RAs from the default router can still be used
by the MN in this scenario to determine "reachability from the router".
Also, the mechanisms used by the MN to determine "reachability from the
router" should not be removed from the MIPv6 specification - this is
important functionality that is not duplicated by NUD.

Details:
I spent a couple of hours researching this with another engineer here (Jason
Schmidlapp) who has a bit more experience with 802.11 than I do, we looked
at the IEEE 802.11 specification together and decided that the 802.11 link
speed issue that Gabriel has reported is a non-issue. As you say:

> Secondly, I don't know e.g. WLAN radio behaviour well enough to understand
> one aspect of the multi-speed problem. If the link layer is capable of
> multiple speeds, why are the router and the host using a "too high" speed
> for their unicast communications? It would seem to me that the right thing
> for the link layer would be to choose the speed that still reaches the
> host.

802.11 does exactly that. The IEEE 802.11 specification discusses link speed
switching in section 9.6 "Multirate Support". It is left up to implementors
as far as when to downshift the link speed being used with a specific peer,
however it is clear that the intent is for a 802.11 access point to monitor
the state of MAC-layer (re)transmissions to a specific MN, and when it
becomes apparent that the MN isn't receiving the unicast packets/frames that
the access point sends it, then the access point will try to improve
performance of the link, one way it can do that being to downshift the link
speed. So, this is all handled by the 802.11 MAC/PHYS layer. Per section 9.7
"Frame exchange sequences", unicast data frames "Directed MSDU or MMPDU"
require acnkowledgement "Last – ACK" by the peer. Also, refer to section
9.2.5.3 "Recovery procedures and retransmit limits" of the IEEE 802.11
specification.

Also (somewhat unrelated), the MN at the 802.11 MAC/PHYS layer can make its
own determination of receive signal strength and signal quality (for
example, the Intersil PRISM chipset passes this information up to the host
interface for every received frame), and based on that can make the
appropriate roaming decisions. This would be a L2 move event initiated by
the 802.11 MAC layer.

To clarify, the problem that Gabriel reports w/ regards to 802.11 using
different link speeds for broadcast/multicast packets versus for unicast
packets, as I read it, it only has to do with the access point transmitting
to the MN: i.e.  since the router uses a faster link speed (i.e. with less
range) for the unicast packets that it sends to the MN than for multicast
RSs (i.e. with more range), then there is the potential for the MN to be
able to receive the RSs from the router, but not the unicast packets from
the same router - and this means that the fact that the MN is able to
receive RSs from its router is not a good indication of being reachable from
its router w/ respect to unicast. However, as I've said above, this is
really a non-issue - it is all handled correctly by the 802.11 MAC/PHYS.

Note that "reachable from its router" is not the same as NUD bi-directional
reachability - that was always clear to me from reading the MIPv6
specification, perhaps you need to add some clarification to the spec about
that. "Reachable from its router" only means that the MN can receive packets
from the router, which says nothing about whether or not the router can
receive packets from the MN.

I disagree with Erik:

> - In addition to the intro, I'm concerned that the changes in the
>   movement detection section (which I think talks about looking at the
>   source link-layer address of packets to determine that the default
>   router is still sending packets to the MN) is unnecessary since it
>   doesn't solve any problem.  If there is only one router on the link
>   then NUD will tell the MN that the router is dead, in addition to
>   the MN being able to detect that it has moved to a different link.

It is still important for the MN to keep track of reachability from the
router. NUD probing of the router is only used when the MN has data to send
through the router. Otherwise, if the MN isn't actively sending any data, it
won't be actively probing the router. If it doesn't keep track of
"reachability from the router" by either listening for RA beacons
(Advertisement Interval) or some other means such as putting the interface
into promiscuous receive move and listening for any frames sent by the
default router (matching on source link-layer address; and note that these
are likely frames sent do a different host on the same link, not to this
MN), then it is possible that the MN goes off link without ever realizing it
(especially if L2 doesn't give MIPv6 the appropriate link-movement
triggers), and then the MN is no longer reachable from the network. Unless
the MN has data to send through the default router, it will not initiate NUD
probing of the default router so it will not detect this reachability
failure in this case. That's why it is important to have some other
mechanism that the MN uses to check for its "reachability from the router".

> I think this is a real problem (though I have a question on it later).
> But why is it hard to follow Gabriel's suggestion of taking this funky
> scheme out of the spec? Here's what we have current for detecting
> router reachability:
>
>      1. Track all packets, not just those sent with router source address
>      1b. As a special case of this, talk about the RAs whose period
>          is known
>      1c. You could even make the interface promiscuous and do the above
>      2. Finally, you can do NUD
>
> First of all, I'm not sure whether Gabriel's suggestion was to take out
> all of #1, or just #1b.

Gabriel, as I read his comments, is talking about removing #1 entirely. I'm
completely against that change - first the 802.11b link speed switching
issue is really a non-issue (I've explained why above), secondly it is
necessary for the MN to monitor reachability from its default router
especially if it doesn't have sufficient L2 triggers to notify it of link
movement. You could snip #1c from the specification, but IMHO that is useful
information for implementors so I'd leave it (even though it is optional
functionality). #2 NUD on its own is not sufficient, because the MN doesn't
initiate NUD probing until it actually has data to send through the router.

> Thirdly, I worry about the impacts of disabling 1b. The trouble with
> NUD is that it works more or less perfectly when there's traffic from the
> mobile node. However, if a number of idle mobile nodes need to track the
> reachability of their router using NUD, this will result in frequent NS/NA
> messages on the link. This is undesireable.

NUD probing only occurs when:
1) the MN is sending data through the router
2) reachability is suspect

TCP should be refreshing the reachability state of the Neighbor Cache entry
for the router periodically (as the MN gets reachability confirmation, for
example a TCP ACK received via the router that acknowledges some new data
sent previously by the MN), so that will elminate or reduce the need for NUD
probing in many cases when the MN is actually sending data through the
router. If the MN isn't actively sending data through the router, no NUD
probing of the router should be occurring. So, your concerns about frequent
NS/NA messages appear to be unwarranted.

Thanks.
- Ed Remmell
Elmic Systems, USA

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]]
> Sent: Sunday, April 20, 2003 11:49 PM
> To: Ed Remmell
> Subject: any ideas for this problem?
>
>
>
> Ed,
>
> This is the one remaining issue from Erik's original IESG comments.
> Any ideas on how to take care of this?
>
> Erik wrote:
>
>  > - In addition to the intro, I'm concerned that the changes in the
>  >   movement detection section (which I think talks about looking at the
>  >   source link-layer address of packets to determine that the default
>  >   router is still sending packets to the MN) is unnecessary since it
>  >   doesn't solve any problem.  If there is only one router on the link
>  >   then NUD will tell the MN that the router is dead, in addition to
>  >   the MN being able to detect that it has moved to a different link.
>
>
> Gabriel wrote:
>
>  > The issue now that I think about it is with this particular mechanism:
>  >
>  > "Since the router sends periodic unsolicited multicast Router
> Advertisements,
>  > the mobile node will have an opportunity to check if it is
> still reachable
>  > from its default router, even in the absence of other packets
> to it from
>  > the router."
>  >
>  > This may not guarantee symmetric reachability to the
>  > router, even if there's only one router on that link. In real life,
>  > it has been observed that if there not all nodes are using
>  > the same 802.11 speed, 802.11 broadcast packets (which may carry
>  > the unsolicited RA multicast by the router) will be transmitted at
>  > the lowest speed of 1 or 2 Mbps, whereas the unidirectional traffic
>  > from a given MN to the router (or access point) may  be
>  > transmitted at 11Mbps, for example. So broadcast traffic has
>  > been seen to reach much beyond what unicast traffic reaches.
>  > This has been observed to cause all sorts of problems with
>  > AODV in experimental setups. The fix to those has been to have
>  > tests for liveness. Only this will guarantee that the link is
>  > symmetric.
>  >
>  > So I'm beginning to think we should delete the text about this
>  > funky mechanism and only leave stuff that is known to work.
>  > Once we do that and we leave only mechanisms (NUD) that
>  > guarantee this, we will be consistent with 2461.
>
>
> So, in conclusion the current text in the movement detection section
> states that we can take the reception of any packet from the router as
> an indication of the routing being able to reach this node. The issue
> in this is that this may not work always, and may fail in an important
> case. Namely, on link with nodes supporting different speeds, it can
> apparently happen that e.g. WLAN broadcast packets are sent on a lower
> speed than specific unicast traffic. This may result in the mobile node
> being able to hear multicast RAs, but not actually be able to receive
> traffic.
>
> I think this is a real problem (though I have a question on it later).
> But why is it hard to follow Gabriel's suggestion of taking this funky
> scheme out of the spec? Here's what we have current for detecting
> router reachability:
>
>      1. Track all packets, not just those sent with router source address
>      1b. As a special case of this, talk about the RAs whose period
>          is known
>      1c. You could even make the interface promiscuous and do the above
>      2. Finally, you can do NUD
>
> First of all, I'm not sure whether Gabriel's suggestion was to take out
> all of #1, or just #1b.
>
> Secondly, I don't know e.g. WLAN radio behaviour well enough to understand
> one aspect of the multi-speed problem. If the link layer is capable of
> multiple speeds, why are the router and the host using a "too high" speed
> for their unicast communications? It would seem to me that the right thing
> for the link layer would be to choose the speed that still reaches the
> host.
>
> Thirdly, I worry about the impacts of disabling 1b. The trouble with
> NUD is that it works more or less perfectly when there's traffic from the
> mobile node. However, if a number of idle mobile nodes need to track the
> reachability of their router using NUD, this will result in frequent NS/NA
> messages on the link. This is undesireable.
>
> OTOH, this is a general problem with IPv6 and wireless links, and
> not something
> that MIPv6 specifically brings out. Nevertheless, I'm not sure
> what I should
> do, given an apparent problem in the way that the current specification is
> written, and a possibly serious efficiency problem if I rewrite
> it the other
> way.
>
> Any suggestions?
>
>