Re: RE: AD request / L2 Triggers Chapter Statement

Phil Neumiller writes:
> > In contrast, the "triggers" proposal changes *nothing* about the bits
> > on the wire.  The bits remain the same; only the internal design
> > (perhaps) changes.
> 
> Yes, this is the whole point.  To this day, IP as defined by the IETF has
> NEVER described how an L2 itself might interface to IP.

Right.  Nor has the IETF described how IP interfaces with buffer
and/or memory management.  Nor how it interfaces with event logging.
Nor what sorts of debug facilities are needed.  These are all
considered to be implementation details that are outside of the domain
of IETF standards.

>  That is indeed
> what we are struggling with.  I realize its a new concept.  Its the wire(s)
> between the link layer and the internet layer that needs specification.

What wire?

> Why *this* was never done escapes me.  The IETF is more than happy to
> say here is a dumb L2 with a payload like this and here is how we 
> stuff IP bits into it.  The IETF heretofore has NEVER been  interested in 
> how an L2 may interpret the TOS field or TTL for instance across an
> L2 tunnel.

Now wait just a minute -- that's a very different thing.  Interpreting
the bits inside the TOS [DSCP] field and changing the per-hop behavior
based on them is indeed an externally observable behavior.  Where
*possible*, I think the L2-specific documents that talk about how to
carry IP over a given L2 should deal with these issues.

I never said differently.  Please don't put those words in my mouth.

The QoS implementation case is utterly different from describing an
"L2 triggers" standard.

>  How can the IETF EVER hope to build QoS if it continues
> to limit itself to this limited method of specification?

Just how did we wander off-topic into QoS?

In any event, the problem isn't (and never has been) in the
comparatively simple problem of querying interface capabilities and
dealing with different feature sets.  Folks who build real IP
implementations have dealt with that issue for decades.  The really
hard problem is in what one *does* with any of those features, and
this proposal doesn't make that hard problem any easier.  That hard
problem accounts for much of the lack of deployment.

>   Perhaps best
> effort is the end-all???   Maybe we don't really need to charge for 
> mobility, QoS, and security?   This is precisely where IP needs to 
> mature.  The bits on the wire may very well be affected (in the 
> time or frequency domain) if IP+xport had a mechanism to allow it.

Certainly.  All the upper-level things are in the domain of the
diff-serv working group to define, and the lower-level bits belong to
the (mostly non-IETF) L2 designers.

> Most wireless interfaces have a variety of speed settings.  Generally the
> longer the distance the slower the speed.  When you add mobility and
> QoS to this mixture it gets real ugly real fast UNLESS IP matures.

I don't see how that's a protocol issue.  It's a design issue.  The
two are quite different.

> My claim, is that IP IS NOT DONE FOR WIRELESS.  Its only
> just begun.  If you shoot me down here in this BOF, other more powerful
> wireless Jedi will follow me!!! :-)  

Hey, knock yourself out.  You don't have to shoot me down to proceed.
If you think it's useful, stop listening and just drive on.  However,
upper case letters to the contrary, I still remain to be convinced
that this helps in any measurable way.

Lloyd Wood writes:
> On Mon, 10 Jun 2002, James Carlson wrote:
> > Given that the changes make no observable difference, how does it
> > matter?
> 
> A similar argument can be made for TCP congestion control algorithms,

Actually, no, it can't.  With TCP congestion control, the differences
can be observed on the wire -- the timewise behavior changes.  What
the congestion control algorithms *don't* specify is how you *must*
implement it.  All they specify is the behavior, in graphic detail.

In the case of these L2 triggers, however, there's simply no
difference on the wire at all.  A box that implements this feature by
proprietary means will be *indistinguishable* from one that implements
it using the new protocol.  There's nothing to observe, because the
feature is purely an internal interface, not an actual protocol.

Phil Neumiller writes:
> > A similar argument can be made for TCP congestion control algorithms,
> > which are merely implementation features that are internal to the box,
> > and do not specify protocol bits on the wire. TCP congestion control
> > is a host implementation feature, and shouldn't be standardised!
> 
> I was going to say the same thing about routing and QoS.  Routing
> affects spacial aspects of the bits on the wire(s) but not the bits.

This is incorrect for exactly the same reason.  Those behaviors are
good examples of things that *are* visible outside of the box and that
can be specified in terms of how the box itself behaves.

Specifying that an L2 interface must send such-and-such signal into IP
on some event is *not* observable outside of the box.

JinHyeock Choi writes:
> Few will doubt that it is useful for the link layer to be able to send event notifications up to IP 
> layer,

Right; no disagreement there.

> especially for fast handover in wireless environment. And if the link layer and the IP layer 
> reside in one system, we can implement the system to send suitable information upward. 

Sure.

> But what if the link layer and the IP layer are in separate systems?

Huh?

If the link layer is on a separate system, then some sort of
networking protocol connects that separate system with the one that
does IP.  That protocol essentially defines a tunnel.

Tunneling protocols already have their *own* signaling for exactly
this reason, and the local endpoint behaves as the L2 layer and
signals (as L2s have *always* done) in a manner appropriate for the
local system.  There's no reason that anything new is needed here.

> What if the link layer in one 
> system wants to send notifications to the IP layer in another system? For example, is it possible 
> for an AP to send a notification to a mobile node or an access router? I think this kind of ability 
> is useful. We found some technical problem can be solved more easily with L2 and L3 
> cooperation. 

That sounds like a different case than the one described above.
You're basically describing integrating L2 reachability information
into L3 -- so that (say) a failure of a bridge or switch port notifies
other hosts on the network so that they can (for example) rip up
ARP/ND entries and reroute traffic.

That sounds like a great idea, but it's not IP, and not part of the
IETF.  I would suggest bringing such a thing up with IEEE or doing it
as a special proprietary hack.

> access router as soon as possible. But there are some problem under current neighbor 
> discovery protocol. For more detail, confer 'Mobility Support in IPv6 (draft-ietf-mobileip-ipv6-
> 17.txt)' 7.5 and 'IPv6 Fast Router Advertisement (draft-mkhalil-ipv6-fastra-00.txt)'. Because 
> of these, the standard (RFC 2461) change is suggested. But we can solve these problems more 
> easily if an AP caches suitable Router Advertisement message and sends it to an arriving mobile 
> node. For more detail, confer 'Fast Router Discovery with AP Notification (draft-jinchoi-
> l2trigger-fastrd-00.txt)'. 

Yes, these are more examples of things that I don't see a need to
standardize.  Everyone who implements this stuff knows that it's a
good thing to send advertisements as soon as L2 goes up.  Is that
something that actually needs to be "standardized?"  Why?

> We believe that the above is not sole example. Moreover it will be nice for other standard body 
> (IEEE 802.11) to nofify them what kinds of triggers are needed to optimize IP 
> performance. Did IETF provide input for 3GPP? 

You're talking about two things, I think.  802.11 emulates an
Ethernet, and 3GPP is using PPP.

> I guess the following questions are to be considered.
> 1) Is L2 trigger useful for Internet? 
> 2) Can we improve the current work on L2 trigger?
> 3) Is it appropriate to work on L2 trigger in IETF WG?
> 
> IMHO, the answers to all are positive as I wrote above.

In my opinion, all of those are negative.

Phil Neumiller writes:
> > And this has significantly influenced the design
> > of the IP and TCP protocols when the Old Arpanet NCP had to be redesigned
> > for a more heterogeneous and wireless environment!
> 
> Yes, and it worked fine for non-realtime, non-commercial, best effort traffic on
> a relatively lightly loaded and a much smaller global Internet.  The bu$iness world
> wants more.  MUCH more.  Mobility is a "chargeable" service.  Why aren't
> mobile Internet service providers popping up?  Because its hard too
> do.

Or because it's just plain unnecessary.  I can use any of IPsec,
Mobile IP, ssh, Kerberos, and L2TP with my mobile connection.  I can
use them all *today* without bothering to pay my ISP extra.

Why would I want to pay extra for something I can already do?

> Why is
> it hard to do?  Because the IETF has become pompous and monolithic and 
> slow to change.

Bah!  I'm going to try to pretend that you're somehow not calling *me*
pompous, but I don't think it's going to work.

>  IP IS NOT PERFECT!  IP over everthing inspired a huge
> growth spurt along with the WWW.  Instead of standing around in awe at the
> marvelous Internet, can we get on with improving it finally????

I've yet to see a proposal that helps.

> > Maybe instead of relying on a connection-oriented subnetwork and dealing
> > with "handover" problems it might be better tu use a basic datagram
> > subnetwork (remember - IP does not necessarily require a "link" layer but
> > assumes what used to be called a "local network") and put the complexity of
> > signaling and end-to-end aspects on a higher layer.
> 
> Jeesh, how can a high layer work blindly!  You are making my point for me!

Blindly?  What is ECN?  What is diff-serve?  How much work has already
been put into this and what does this proposal actually contribute?

I'm really failing to see how this minor local interface hack -- which
already exists, albeit in proprietary forms, in all of the systems
I've ever used -- actually helps extract the fine *path-related*
information that's required.  All the world isn't in that last hop.

> > implement artefacts such as slow start and a separate congestion window in
> > order to do a good job. In my opinion this is the real problem we are facing
> > and the question remaisn whether this is a "protocol" issue or an OS issue;
> > in this respect I like the ISDN Refernce model which has separate "planes"
> > for these aspects.
> 
> ...and these issues with TCP are complained about bitterly in the various
> transport WGs.  Isn't the solution becoming obvious???

Yes and no.  One thing that's obvious is that getting L2 information
about the very last hop tells you precisely *nothing* about the state
of the network on the N-2 other hops between the communicating peers.

> > TCP has never been designed as a real-time end-end protocol; maybe the
> > wireless people ought to define such a beast on top of IP and use the packet
> > radio techniques for the wireless network instead.
> 
> We are in the process, but we keep running into people that want to impede
> our progress!! :-)  The first step in building a closed loop control system for
> handover, mobility, routing, and QoS is the feedback loop, i.e. L2 TRIGGERS!!!

L2 triggers so far just talk about link up/down.  Where, exactly, is
this feedback loop?

Phil Neumiller writes:
> A more systemic question might be is IP mobility important to the Internet 
> community?  Let's face it, mobile IP has seen scant deployment in its
> years of existence.

True.

>  Why?

In part because there are solutions that work just fine and are
nowhere near as complex.  It's a classic optimization problem: Mobile
IP attempts to address *all* of the problems, and solutions that
address just some of the interesting problems turn out to be easier to
deploy and use.

>  Obviously its missing thing that would make it
> commercially viable.  The 3G guys worked hard to add some of these,
> but 3G is not necessarily moving that fast.  The hot spot, WLAN, WPAN,
> ad hoc, mesh community is moving much faster.  There are many cheap
> radios available here and much more can be done with them quickly.
> L2 triggers are a win-win since they benefit 3G, 4G, WLAN, WPAN,
> mobileip, and MANETs.  

I agree that L2 involvement is necessary to make IP interfaces work
nicely.  But how does that involve a new specification of any sort?
It's already the case that link up/down notification is a standard
part of every decent IP implementation.  Are we saying that by writing
a new document, we're going to somehow make the crummy implementations
good?  That just doesn't seem likely to me.

Alper E. YEGIN writes:
> Precisely. 802.11 is an example where wireless L2 (access point) does not
> have to
> reside on the access router. Therefore, wireless L2 might be aware of
> certain
> events (link up, link down) per client, but communicating this to the
> interested
> party (i.e., access router) requires a protocol between two.

Yes.  This is really an 802 problem, and it should be addressed there.

Mc.Ky writes:
> > ...and these issues with TCP are complained about bitterly in the various
> > transport WGs.  Isn't the solution becoming obvious???
> >
> For very good reason the ISDN people have come up with a 3-dimensional
> Reference Model where certain aspects of signalling, resource management and
> inter-layer coordination are delegated to separate planes in "the third
> dimension".

Right.  It's exactly this that I'm hoping we can avoid.

> TCP has attempted to resove some of these problems and it seems to me that
> we are now attempting to look for simioar kludges for IP - instead of
> accepting
> the fact that we need a "control" plane with its own protocols for
> inter-layer
> coordination and singaling.

That is, as I've said many times before, a local design problem.  It
has nothing to do with any of the things that the IETF cares about.
It doesn't affect the bits on the wire.  It has no effect at all on
interoperability.  If folks want to standardize design issues, that's
great, and there are many standards bodies that are willing to do it,
but the IETF isn't the right one (or even a good one) for the job.

> The question is: should the IETF get into this field or not? IMHO - if I
> look at
> what is happening with MPLS we are already in there!

Again, that's a different case.  MPLS and the associated signaling
protocols *are* defined in terms of bits on the wire.

You can implement MPLS any way you like *inside* your box.  You can
pass messages.  You can make function calls.  You can even invoke O-O
"methods."  Anything at all.  What matters in terms of the IETF is
that the bits that come out are somehow conformant with expected
behavior and interoperable with other implementations.

L2 triggers affect neither behavior nor interoperability.  They're
strictly internal.

James Kempf writes:
> I'd like to add slightly to Behcet's rsponse. As our work with Motorola
> and Behcet's work shows, it should be possible to utilize Layer 2
> triggers with current 3G radio protocols, but not necessarily with
> current 3G radio access networks. Reduction of handover latency requires
> modifying the connection-oriented model to reduce the amount of state
> involved in maintaining a connection with the mobile node.

But do these L2 triggers appear outside of the box?

The main issues I see addressed in this presentation appear to be:

	- lack of indication of remote port failure on an 802 bridge
          (a well-known problem), and

	- an implementation that doesn't solicit for a new router
          advertisement when the link status goes up again (apparently
          an implementation flaw).

While I agree that the former is a significant problem, I don't agree
that it's something that ought to be addressed by way of the L2
triggers draft, or even necessarily in the IETF.  Optimizing the
important failure cases by providing some indication that reachability
of a remote link has been lost in a bridged network is a significant
issue for 802, and is one that needs to be addressed at the L2 level.

As a counter-example, L2 layers that are defined differently (e.g.,
PPP) do not suffer from this design flaw.

-- 
James Carlson, Solaris Networking         <[email protected]>
SUN Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677


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