Re: RE: AD request / L2 Triggers Chapter Statement

Phil Neumiller wrote:
...
> Before I do that, I want to state that many new 3G/4G/MANET type of devices have pretty
> beefy real time OS's and can communicate across many simultaneous links that come and go
> on milisecond time scales.  Although your virtual link sounds like a nice idea I would recommend
> that you carefully study SCTP multi-homing because it can do this already and is an RFC.

SCTP, though an RFC, is not (IMO) the best solution here. We implemented 
a system that did dynamic failover using existing standard RFCs several 
years ago:

"Dynamic Host Routing for Production Use of Developmental Networks"
J. Touch and T. Faber, Proc. ICNP '97, Atlanta, Oct. 1997, pp. 285-292.
http://www.isi.edu/touch/pubs/icnp97/icnp97.ps

SCTP embeds too much of these standards inside the transport protocol 
(you might want to review the mail archives of their WG; you'll find my 
posts on this topic there).

>>OK - so we agree to disagree on whether anyone would use this 
>>information.  My concern is that no existing protocol does anything 
>>anywhere near this fast in the Internet; the simple variability in paths
>>is enough to kill most 'hard realtime' guarantees on timing. As a 
>>result, it isn't clear that they COULD (perhaps not enough to convince 
>>you, but can you convince me??).
> 
> 
> There are two cases here that are of utmost importance.
> 
> 1).  The edge device managing multiple 10E0-02 links and attempting to
>        multi-home across them and handover seamlessly.  Dropping packets
>        (specifically VOIP and or other codec packets) is usually a bad thing.

IP is predicated on the fact that dropping packets is just fine.

If this is related to handoff between two links in the same technology, 
it is an intra-link (e.g., inside ATM, as an analogy) issue.

 >  IP was not
>       originally conceived for handoffs. 

Agreed.

 > IP is an evolving creature.  The world
>       is going mobile and IP must too.

Again, as others have pointed out, this requires a revision of the 
entire Internet architecture. Starting here isn't going to help; the 
result will be triggers to a non-existent (and un-contemplated) 
internet-wide facility.

> 2).  Routers that have several heterogeneous or homogeneous wireless links
>        also need to collect link statististics to ensure quality of service.       

Stats can be gathered by posting info in SNMP databases.

>>>>What I'm asserting is:
>>>>
>>>>if it's within two links of the same type, a meta-link can do it
>>>
>>>
>>>Yeah, and where is this defined in ANY commercial IP stack???
>>
>>No. And rightly so. That would be inside the link layer.
> 
> How exactly would these two link layers talk to each other?  Each would have
> its own IP address right?

In this case, it may be useful to revisit that decision. If the links 
are acting as backups, either they share an IP address (and the link 
layer determines which is active), or there is an IP layer above them 
(tunneled).

>>Can you be more specific (and less inflammatory, please?)?
>>E.g., a policy based-routing that would _change_ what it does on a 
>>millisecond timescale. Granted that policy routing operates on those 
>>timescales, but it isn't clear that anything it does would change on 
>>those timescales.
> 
> The argument is circuitous.  What we are saying here is that the is a NEED
> to do this for seamless handover.  We are not sayint that anything does this 
> now.  If you are happy with MANET, and MIP handovers as they stand, then
> we can all go home.  If you feel that there is something lacking with respect
> to link knowledge being propagated upward to IP and transport then we
> have work to do here.

I agree that this is a circular argument. The problem is that the rest 
of the circle is large and unaddressed. There's insufficient 
justification to deal with this small arc of the circle to 'trigger' 
fixing the entire rest.


> 
> 
>>>Especially with respect to
>>>wireless handovers which is the MAIN purpose of this discussion.
>>
>>Wireless handovers is a link-layer issue, not necessarily an IP-layer
>>issue.
> 
> IP over everything.  Dumb network, smart host.  What you are suggesting
> is an IP architecture violation.

IP _OVER_ everything, not under or inside everything. You want 
in-network state (otherwise there wouldn't be handovers); which means, 
de-facto, you don't want IP for this layer.

> Handover decisions need to be above the IP layer so that routing can be involved.
> How on earth would mobileip and MANET cooperate if the link layer handled the
> handovers and there was absolutely no standard way to communicate this to the
> IP layer. 

No - _why_ would mobileIP and MANET need to cooperate? You haven't made 
that point yer.


>>- we NEED all of IP to change to be realtime to USE L2 triggers
> 
> Hmm.  This seems a bit sarcastic to me but I will go with it.  No.  We need an input
> queue (can be implementation dependent) on the underside of IP that can accept
> events that occur on millisecond time scales.

To send to _what_? Again, nothing in IP will react to things on these 
timescales. If it's on the _underside_, you can't know what it's going to...

>>- everyone NEEDS all of this to support one link type for
>>certain applications
> 
> No.  The beauty is we do this once and every L2 from here to eternity works
> seamlessly.  You have it completely backwards.

You're still thinking about the link layer; try thinking about the 
routing protocols, the transport protocols, and the applications - THEY 
are the ones who will suddently have to care about events on millisecond 
timescales (they don't now). And, if the signal is on the underside of 
IP, unless they ALL do, you can't assume ANY do.

>>Sounds a lot like optimizations.
> 
> Yes to the design of the underspecified IP underbelly.  No harm in standardizing
> optimizations last time I checked.

The IETF as a rule doesn't do this. Optimizations are "informational" at 
best.

Joe



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