Re: RE: AD request / L2 Triggers Chapter Statement

> Phil Neumiller wrote:
> >>The whole of L2 Triggers assumes that:
> >>
> >>1) events occur at the link on the timescale of milliseconds
> >>2) these events must be communicated to L3
> >>3) L3 can do something useful with these triggers
> >>
> >>#1 is granteed, but #2 assumes that #3 ever occurs. There is little in
> 
> >>IP as a whole that supports such "realtime" requirements of
> millisecond 
> >>responses. In fact, that's in opposition to most of the rest of the 
> >>Internet architecture.
> > 
> > 
> > Yes.  That IS the point.  There needs to be. 
> 
> But there isn't; IP currently won't do anything interesting with info on

Right, but many routing systems are built ON IP and below transport.
Take MIP, any MANET protocol, ICMP itself, OSPF, BGP4, etc.  All of
these systems that reside at the IP layer in routers CAN INDEED make
extremely good use of this information.

> 
> that timescale. It's like calling up someone who won't answer.

This can be throttled back and discovered.  Hosts with slow time constants
can make this know to the L2 via the API (underbelly interface).  The L2
can querry the IP layer and find out how fast it can accept events.

> 
> > If IP were to create a nice
> > home for L2s, life would be much simpler for wireless system
> providers.
> > Wireless links stink.  They come and they go.  IP was build for
> 10E0-06 
> > or better BER links.  This needs to change.
> 
> Yes - but, as I suggested later on, it can change by creating a wireless
> 
> virtual link that goes over different wireless physical links, ala ATM. 
> It need not involve IP.

This is not practical for routing systems.  This is what SCTP multi-homing
can do for you or other TRANSPORT layer QoS mechanisms such as 
RSVP.  Policy based routing requires this AT the IP layer.
> 
> >   Applications include but are not limited to:
> > 
> > o      Fault tolerant failover of links
> 
> Usually within a single link layer type - i.e., from one 300Mhz wireless

This is where you are completely missing it.  The whole point is for routers
with several heterogeneous wireless links to policy route over them in the
event of failure.  I think you are thinking in terms of a simple host.  Think in
terms of what a MANET or router gains from this.

> 
> > o      L2 signal quality indications
> 
> To what end? What would IP do differently?

It would most likely simply convey this to the transport layers that have
registered interest.  It may do this with an ICMP message.

> > o      L2 congestion control
> 
> Again, to what end? IP doesn't have congestion control; TCP doesn't 
> react on milliseconds.

TCP DOES react in milliseconds on the boxes (routers) and hosts I work
on.  It will get even faster as time goes on.

> > o      L2 fragmentation control
> 
> There's an existing mechanism for that - MTU. Does it change on the link
> 
> on the fly?

In many instances it would be very NICE to have the option.  QoS queueing
mechanisms can benefit greatly from such capabilities.


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