Re: On Link Triggers (implementation)

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

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
> the infrastructure can have nothing in common with the old path, so
> 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
> you do Horizontal-Handoff, it's handled entirely withing layer 2 so
> transparent to L3.

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.

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

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
> compare how connectivity is managed on braodcast links and connection
> oriented links.

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

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

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.

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

I thought we were talking about implementation details :)

> 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

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.

> that some policy should happen between those events and M-IP triggers,
> 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

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