Subject: [pilc] On Link Triggers (implementation)

From: Jean Tourrilhes <[email-masked]>
Date: Tue, 24 Sep 2002 15:57:29 -0700

Hi,

	I quickly scanned through the Link Trigger discussion on the
mailing list (don't have time to read all that). Maybe I should add a
few comments (and sorry if I re-ignite a flame war).
	I've recently wrote a little protocol call P-Handoff. It is
totally off topic, apart from the fact that to implement this
protocol, I needed Link Triggers, which of course I also implemented
(my bad habit of implementing before talking about it).
	So, maybe my practical experience can be of some use to some
of you (or maybe not)...

1) Implementation status
------------------------
	All implementation done on Linux only.
	Implemented for Wireless LANs (802.11, ...) through the
Wireless Extensions (Wireless Events) since early 2002. Standard in
Linux kernel 2.4.20-pre2 and higher. Not all WLAN driver do support
it (See my web pages for more details).
	Implemented for IrDA (IrNET) through the IrNET control channel
since early 2001. Standard in most 2.4.X kernel.

2) Mechanisms
-------------
	I fully agree with few people, the mechansisms to deliver
those trigger are totally OS specific.
	For example, under Linux I use the RtNetLink socket, which is
also used for most management messages (new/del routes, interface
up/down, ...). I expect that other OSes would have more appropriate
mechanisms.
	I also use different mechanisms for different link layers, but
that's mostly an accident ;-)

3) Semantic
-----------
	My personal belief is that the semantic of those events is
link specific, therefore I believe that it won't be possible to
standardise them across all link layers.
	I'm not talking about the small stuff, such as the fact the
WLAN events carry a IEEE 48 bit address while IrDA events carry a
random 32 bit address. Most often the meaning of the event as well as
the action to take on it is different.
	I guess I'll have to go through an example on that one ;-)

	These are the "failure" events that I've defined and could be
used to trigger Vertical-Handoff.
	WLAN events :
	o SIOCGIWAP(addr) : Successfully registered to Access Point
with address 'addr'. If 'addr' is NULL, it means that we could not
find any Access Point suitable (out of range). This is generated at
the end of the link layer handoff.
	o IWEVTXDROP(addr) : Packet sent to 'addr' was dropped due to
excessive retries.
	o SNR : this is not an event, but you can poll the SNR for
each peer through iwspy (updated on Rx'd packets).

	IrNET events :
	o Disconnected(addr) : IrDA stack closed the link connection
to peer 'addr'. May be due to link failure (12s timeout) or explicit
disconnection from one end. At this point, the IP interface is going
to be destroyed.
	o Link-Blocked(addr) : Peer 'addr' failed to turnaround the
link layer. We have not heard from the peer for one second (max link
turn around time in IrDA is 500ms). However, the connection to the
peer still has not timed out.

	As you can see, the semantic of those events are very
different, and you really need to understand in which cisconstance
they are generated to make good use of them.
	For example, if you want to trigger vertical handoff on the
"Link-Blocked" event on IrNET, you have to remember that you need to
explicitely disconnect the IrNET connection.
	On the other hand, you may want to accumulate a few IWEVTXDROP
events before doing anything to avoid false positive due to long fade
on the wireless channel, especially if your number of link level retry
is small. For example, you may want to only start pre-allocating the
backup path on the first event, and to really switch only after 3 or 4
events. But, you also need a fallback to IWEVTXDROP, because it will
be generated only if there is outgoing traffic (as opposed to other
events that will be generated in absence of traffic).
	And don't expect any SNR on IrDA ;-)

	Yeah, you could probably defined some meta-events abstracting
and encapsulating the link layer events in some form (like "something
bad happen on the link"). Actually, nobody prevent you to define your
own set of standard events on the low level events I've defined.
	But in that case you would loose the benefit of the approach,
which is to have a precise and dependable status of the link layer
(which is needed to know exactly what's happening).

4) Timing
---------
	Those events don't have to be fast, but they have to be
precise. None of the events I've defined is really fast, apart from
IWEVTXDROP.
	For example, SIOCGIWAP occur *after* L2 handover. Most L2
handover on 802.11b take in the order of one second. On the other
hand, the L2 state after this event is stable, and you don't run the
risk of having L2 handoff and vertical handoff happening in parallel.
	Same for the IrNET events. By design, the link layer is not
going to give you anything faster than that. Most wireless links need
to average bad channel and fading on relatively slow time (order of 1
second) through the use of ARQ/FEC/interleaving/diversity, so you need
wait patiently while the link do its job.
	I personally believe it's more important to make the decision
right than to make it fast.

5) Where do events go
---------------------
	Some people have suggested that those events should go up the
IP stack. I personally don't think that this is the best approach,
because this is not where those events are needed. And also I don't
want to polute the TCP/IP higher layer interfaces with link specific
stuff (this is about layer separation).
	Another way to look at this : TCP/IP connections are mapped on
links through the IP routing table. Not all links may have a route
configured on them. A TCP connection may be migrated from one link to
another, or even "bonded" on two of them. I don't see how you could
get any way to map link information to TCP connections in any
meaningfull way.

	For me, the events go sideway, directly into the management
plane (so, staying within layer 2, and not going to layer 3). Very
similar to the link layer configuration (ESSID, WEP) that is done
totally outside the TCP/IP stack (so, it's not a surprise that I
implemented those events in the link management channel). TCP/IP
doesn't have to know about those events, they are purely a link API
issue.
	I would expect that the main use of those events would be for
user feedback ("your battery is flat and your connectivity shaky") and
other things that are totally unrelated to TCP/IP.
	On top of that, the MobileIP manager or the AODV manager could
connect directly to the link interface to get those events and would
manipulate the routing table according to those (most OSes have well
defined APIs to manipulate routing table).

	So, I guess that people interested in Link Triggers just need
to download their favorite Linux distribution, get a 802.11 card and
and start playing with it and making their own informed opinion ;-)
	Have fun...

	Jean
_______________________________________________
pilc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pilc
http://www.ietf.org/html.charters/pilc-charter.html
http://pilc.grc.nasa.gov/

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Tue, 24 Sep 2002 21:47:07 -0700

Hi Jean,

Thank you for this very useful report...
Few comments...

> 2) Mechanisms

I believe your implementation and experiments were
for observing triggers on the wireless client side, rather
than the network side, right? Because if it is the network
side, then you'd see where these triggers are generated
(e.g., access point) and where they are consumed (e.g.,
access router) might not reside on the same node. 
Therefore OS-specific methods are not sufficient...

> 5) Where do events go

Have you looked at:
http://www.ietf.org/internet-drafts/draft-manyfolks-l2-mobilereq-02.txt

> defined APIs to manipulate routing table).

It really depends on where Mobile IP manager is implemented.
For Mobile IPv4, it's likely to be mostly a user-land daemon,
whereas for Mobile IPv6, kernel implementation is dominant.
For latter, clearly these triggers need to be passed to the IP
module.

Regards,

alper

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Tue, 24 Sep 2002 21:47:07 -0700

Hi Jean,

Have you looked at:

Regards,

alper

---

From: Jean Tourrilhes <[email-masked]>
Date: Wed, 25 Sep 2002 10:02:04 -0700

> Therefore OS-specific methods are not sufficient...

	I can't make a case on where those events would be used on the
network side of things, especially that mapping an event to a
recipient of the event become black magic (L2 doesn't know about IP
peers). If the client decide to do a Vertical-Handoff, the new path to
the infrastructure can have nothing in common with the old path, so
finding the common router between two path is tricky business. And if
you do Horizontal-Handoff, it's handled entirely withing layer 2 so
transparent to L3.

	Don't get me wrong, there is still things we need to do in the
infrastructure to help.
	I believe that we need EHN, Explicit Handoff Notification,
which would work more or less the same way as ECN. It would be
generated at layer 3 when the client to a Vertical-Handoff (i.e. when
manipulating IP routing tables) and sent to the remote peers (the
other end of the TCP connections). The purpose of the event would be
to speed up the TCP adaptation to the new bandwidth/RTT/MTU which
might be quite different than on the old path (thing 802.11a => GPRS
handoff). A router could also generate a EHN if it does a handoff
within the infrastructure (but that's less likely).
	There is a big difference between the two events. In the first
case, you only know that the link is flaky, but you have no idea
what's going to happen and what you should do about it. In the second
case, you know *precisely* what is happening and what should be done.

> http://www.ietf.org/internet-drafts/draft-manyfolks-l2-mobilereq-02.txt

	Apart from Vertical Handoff (which I described below), I don't
see new use of it within TCP/IP. And I still believe that at least in
the short run, the end user is the primary consumer of those events.
	Your document also has IMHO a simplified view of link
layers. You can't really compare the situtation between 802.11 in
infrastructured mode (handoff will happen) and 802.11 on ad-hoc mode
(peers will become unreachable, no handoff). And you also can't
compare how connectivity is managed on braodcast links and connection
oriented links.
	The document also call for events "Sufficiently before L2
handover start". For performance reasons, the L2 handoff is initiated
as soon as we know it should be done (and during handoff your wireless
connectivity is interrupted while the link performs wireless
discovery). Yes, I would also prefer if things were totally
predictable.

> For latter, clearly these triggers need to be passed to the IP

	Beeing in the kernel doesn't change anything, that's just
implementation details. The Mobile IPv6 kernel module just need to go
down to the link layer to get those events. I've actually changed my
Wireless EXT API last year to allow kernel modules to hook to it.
	Actually, I believe that stuffing everything in the kernel
just because it can be done is a bad habit. For example, I believe
that some policy should happen between those events and M-IP triggers,
and that's probably involving user space.

	Have fun...

	Jean

---

From: Jean Tourrilhes <[email-masked]>
Date: Wed, 25 Sep 2002 10:02:04 -0700

Have fun...

	Jean

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Thu, 26 Sep 2002 18:26:04 -0700

> peers).

L2 should simply provide the information to its subscribers.
Let the subscribers (consumer of the trigger) decide how to use it.

> If the client decide to do a Vertical-Handoff, the new path to
> finding the common router between two path is tricky business.

Again, this is the problem of the consumer of this information, not L2.
If you want to know one way of using such triggers, please
see
http://www.ietf.org/internet-drafts/draft-ietf-mobileip-fast-mipv6-04.txt

> And if

This is an assumption. Not all inter-technology handovers are
handled at L2. Some cross IP subnet borders, therefore need
to involve IP layer mobility management.

> (peers will become unreachable, no handoff).

Maybe we should clarify this in the draft. This was all about
infra-structure
mode. As you point out, we might need some other semantics for
ad-hoc mode operations...

> And you also can't

This one, I didn't understand. Does this effect the semantics of link-up
and link-down?

> discovery). Yes, I would also prefer if things were totally

This is also an assumption. It really depends on the specific link-layers.
For example, on CDMA2000, after the mobile is in L2 handover process,
it still has a window of opportunity to send one or two IP packets.

> implementation details. The Mobile IPv6 kernel module just need to go

I thought we were talking about implementation details :)

> just because it can be done is a bad habit. For example, I believe

Sure, "where something can be implemented" is the last criteria in
determining where it "should" be implemented. I wasn't suggesting this
as a reason anyways.

> and that's probably involving user space.

[at the riskof deviating from the subject] just because something might have
a configurable policy doesn't mean that it cannot be implemented in the
kernel.
Things that are implemented in the kernel might very well have a user-land
control/management interface.

Regards,

alper

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Thu, 26 Sep 2002 18:26:04 -0700

Regards,

alper

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 26 Sep 2002 21:01:02 -0700 (PDT)

Hi Jean,
  Thanks for posting this information. 
My question is, you state that it takes about 1sec to
complete link layer handover which I found very long
and somewhat discouraging if you consider real-time
communication such as voice-over-IP. 
  Do you think that during this period no IP layer
activity can take place?
  If yes, then I think what Mobile IP WG is trying to
do to have fast Mobile IP handovers is simply
impossible, e.g. the mobile trying to inform the old
access router of the new access router, etc.

--- Jean Tourrilhes <[email-masked]> wrote:

--behcet

__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com
_______________________________________________
pilc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pilc
http://www.ietf.org/html.charters/pilc-charter.html
http://pilc.grc.nasa.gov/

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 26 Sep 2002 21:01:02 -0700 (PDT)

Hi Jean,

--behcet

---

From: gabriel montenegro <[email-masked]>
Date: Fri, 27 Sep 2002 10:31:02 +0200

> access router of the new access router, etc.

Jean, I also thank you and encourage you to look at a
recent document being discussed in the Mobile IP WG
regarding fast handoff over 802.11 (please see attached
message).

Thanks,

-gabriel

Subject: [mobile-ip] New Draft on FMIPv6 over 802.11
From: Pete McCann <[email-masked]>
To: [email-masked]
Date: Wed, 25 Sep 2002 13:39:45 -0500

Hello,

Yesterday I submitted a new draft that describes how the FMIPv6 work
might apply in an 802.11 network.  It has appeared in the
internet-drafts directory and you can find it at:

http://www.ietf.org/internet-drafts/draft-mccann-mobileip-80211fh-00.txt

Please read and comment (preferably in that order).

I think I have found significant issues with both of the main
approaches that were proposed in fmipv6-04.  I hope this draft can
contribute a dose of reality to the discussion going forward.  I
think there are several opportunities for closer collaboration with
link-layer standards bodies like the IEEE, once some of these issues
are understood.

-Pete

---

From: gabriel montenegro <[email-masked]>
Date: Fri, 27 Sep 2002 10:31:02 +0200

Thanks,

-gabriel

Hello,

-Pete

---

From: Jean Tourrilhes <[email-masked]>
Date: Fri, 27 Sep 2002 09:36:56 -0700

> communication such as voice-over-IP. 

	I wasn't talking of the handover time, I was talking of the
time to get a trigger. And it's not always one second, that's an
oversimplification.
	In details :
	o IrDA : connection blocked trigger will be one second.
	o 802.11 managed : The trigger is NEWAP, which is the end of
the L2 handoff. The L2 handover may take up to 1s (probe_time *
num_channels). You probably should do your V-Handoff only when you are
sure that the L2 handoff did fail.
	o 802.11 ad-hoc : first trigger will probably be in the order
of 100ms (using TXDROP, (contention_time + transmission_time) *
retry_max - assuming there is active traffic to that node). To avoid
false positive due to long fade, you may want to wait for a few events
before making the final decision.
	If you are actively monitoring the SNR on 802.11, you may be
able to predict the trigger (but not always).

>   Do you think that during this period no IP layer

	Nope. The trigger above come at a point where you have already
lost connectivity (for the time I describe above).

> access router of the new access router, etc.

	You can do better. For example, on 802.11 you can monitor the
SNR to predict the trigger in advance. But, this require to be very
intimate with the characteristics of your radio receiver, and there is
a nice tradeof between advance time and false positives, so this would
have to be set in function of the required QoS. And also you have a
nice interaction between L2 and L3 handoff.
	If you have regular Internet traffic (HTML, FTP, media
streaming and co), the 1s trigger above will be plenty enough. Only in
the case of VoIP you need to do better.

	Have fun...

	Jean

---

From: Jean Tourrilhes <[email-masked]>
Date: Fri, 27 Sep 2002 09:36:56 -0700

Have fun...

	Jean