Re: RE: AD request / L2 Triggers Chapter Statement

Phil Neumiller writes:
> With respect to something belonging in the IETF or not, I would remind the commenters
> to examine the following RFCs.
> 
> RFC-894, IP over Ethernet
> RFC-2669, IP over cable modems
  ^^^^^^^^ just a MIB
> RFC-2067, IP over HIPPI
> RFC-2176, IPv4 over MAPOS 
> RFC-1577, IP over ATM
> RFC-2143, IP over SCSI
> RFC-2734, IP over IEEE 1394
> RFC-1209, IP over SMDS
> RFC-1088, IP over netbios
> ... ... ... .. I could keep going for a LONG time... ...  ...

All of these define what the bits look like on the wire when you use
IP over foo.  The bits are slightly different in each case because of
the vagaries of each L2.

In contrast, the "triggers" proposal changes *nothing* about the bits
on the wire.  The bits remain the same; only the internal design
(perhaps) changes.

> Hmm, do I see a trend here?  Don't you think by now, we could have said that there are
> some commonalities for IP over X?   Also, don't you think by now we could have standardized
> some of the other half of the protocol?  IP uber alles was nice, but it is a dated concept.  Protocols
> flow in two directions, that is both signalling an bearer channels, why must we retain our strictly
> top down perspective in the IETF, i.e. IP over X?   "IP binds with X" may be a more mature
> perspective.  This gives some respect to X and accomodates X a bit more. 

This is the problem.  IP doesn't define any signaling at all, and this
draft seems to assert that it ought to.  I'm not sure that this
definition would be useful enough to be worth the effort.

If it does, then it needs a much deeper treatment than "IP binds with
X" -- it needs some description of how it actually interacts with
transports and (of particular importance) routing protocols.

In any event, such a description still doesn't rise to the level of a
protocol.  Nothing outside of the system in question can see it.  Why
standardize it in the IETF where such external protocols are normally
standardized?

> As far as the bits on the wire is concerned, this is most definitely the most critical issue.  i.e.
> how many of them am I getting of those I am supposed to be getting over time period t?

I'm afraid you may have misunderstood at least what I was writing.

The "bits on the wire" phrase is a reference to the actual signaling
bits (the 1's and 0's) and the meaning of those bits on the wire.  In
other words, protocols.

I don't see that this draft is talking about protocols at all.  In
particular, suppose we have one system that uses ad-hoc methods to
determine when and how to signal the local IP *implementation* about
link usability, and another implementation that follows the standard
as set by this to-be-written draft.  Suppose that the ad-hoc
implementor is smart enough to make his implementation as "fast" the
other, by whatever definition of "speed" you choose to use.  Do these
two things interoperate or not?  Is the difference between them
externally visible?

If they do interoperate, then we're no longer talking about bits on
the wire.  We're talking about implementation features.  I think that
it's at best dangerous to standardize implementation features because
of the quite obvious problem of tilting the interoperability playing
field towards one vendor or another.

Given that the changes make no observable difference, how does it
matter?

> Is this
> link broken?  Do I need to send smaller packets?  Do I need to adjust my data rate?  Do I need
> to change the channel coding?  Do I need to change the power?    Many wireless devices will
> all pretty much have the sames kinds of problems that they need to communicate to the IP
> stack and upper lauyers.  I can't build a radio that will support QoS for all IP implementations
> unless IP standardizes this bottom half signalling interface.  Then maybe I can attempt it.

Granted; there are all sorts of proprietary issues with each L2.
That's still an implementation issue: how do you design a system such
that the necessary information gets from IP down to the bare metal?

It's no different from the *large* number of IP-to-OS issues that need
to be solved in any real system: how does IP allocate memory when it
needs to?  How are statistics kept?  How is debugging enabled?  How
are CPUs identified to aid in keeping caches hot?  And so on ...

> Some folks are posting rather alarmist statements like "all of IP will have to  change" and that is
> simply not true. Yes, this is a "roots" issue, but what's wrong with that?  Almost everybody that
> has worked on IP mobility for a spell has identified L2 triggers as essential to IP going forward.
> Our twist here is that we want to make a standardized home for them in the IP underbelly. 
> We also want to add a subscription service to the top side.  Some triggers will just terminate
> in IP and others will be fanned out to transports that have registered interest (and a rate they 
> can specify).  The fact that I get the event is much more important than acting on it immediately.
> This is why IP has to become a bit of an event buffer.

That sounds like an interesting system architecture.  However, it's
still not a protocol.  It's a system architecture.

> Wireless X's are VERY MUCH different than wired X's?  IP needs a bit of a tune up to
> better support wireless devices.  It would be really nice if wireless L2s behaved like wires
> but they DONT.  If you made them work like a wire then that would be a violation of the
> end-to-end principle.

Nobody is suggesting that.  What I'm suggesting is that the features
of wireless listed here (fast up/down notification, in particular) are
not at all novel features in the world of IP.  There are many systems
out there that deal with millisecond-scale notification for (for
example) SONET.

The suggestion in the draft is that *somehow* IP doesn't deal properly
with this.  I'm disputing this, and I'd like to see a response that
refers to the problem in the established protocol itself, and doesn't
refer to a particular (and flawed) implementation.

>  Its better to put decisions about what to do with the link in the users
> hands right?

I don't think it's a good thing at all to fix implementation flaws by
adding new standards.  If the problem is that there are
implementations that don't get the existing standards right, what hope
is there to improve things by adding yet more standards documents?

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