Re: On Link Triggers (implementation)

On Tue, Sep 24, 2002 at 09:47:07PM -0700, Alper E. YEGIN wrote:
> 
> Hi Jean,
> 
> Thank you for this very useful report...
> Few comments...
> 
> > 2) Mechanisms
> > -------------
> > I fully agree with few people, the mechansisms to deliver
> > those trigger are totally OS specific.
> 
> 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...

	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.

> > 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.
> 
> Have you looked at:
> 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.

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

	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.

> Regards,
> 
> alper

	Have fun...

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