On Sun, 7 Jul 2002, James Carlson wrote:
> Lloyd Wood writes:
> > On Fri, 5 Jul 2002, Joe Touch wrote:
> >
> > > Phil Neumiller wrote:
> > > > I am sorry about that "sand" comment. It seems the arguments
> > > > quickly get circuitous. What we are suggesting is something
> > > > really subtle.
> > > >
> > > > A). IP needs to create a standard interface method on its
> > > > unspecified bottom half. B). It already has one on the top,
> > > > namely sockets.
> >
> > sockets isnt' a standard.
> > streams isn't a standard.
>
> That's not quite the case. Both are standardized in the SUSv2.
> Sockets is in the XNS:
>
> http://www.opengroup.org/pubs/catalog/c808.htm
>
> and the STREAMS user-level interface is in XSH and XBD, which are also
> IEEE Std 1003.1-2001 (POSIX).
>
> The kernel bits are also standardized. DLPIv2 is C811:
>
> http://www.opengroup.org/pubs/catalog/c811.htm
>
> TPI is C810:
>
> http://www.opengroup.org/pubs/catalog/c810.htm
>
> and, of course, the SVID.
Right. You've cited several different standards from several different
standards organisations. That's not the single 'standard interface
method on the top' that Phil was alluding to, because there is no such
one method.
(Getting a standards body to announce that a specification is fixed
and documented as a standard doesn't make it a universal standard.
All it means is that you've found a (self-appointed?) standards body
that will accept it and provide change control.)
> Just because something isn't part of the IETF doesn't make it
> "non-standard." Just because something *might* need to be
> standardized does *not* mean that it needs to be done within the IETF.
>
> There are many groups that are equipped to deal with standardizing
> software interfaces for various platforms. If you're interested in
> contributing to that work, then I do recommend that you join such a
> group. The IETF isn't the 'droid you're looking for.
>
> > > > This is quite different than saying, all L2s must do this or that.
> > > > What we want is a mechanism to pass L2 information in a standard
> > > > way up to and through the IP stack.
> > >
> > > Given that IP is stateless and connectionless,
> >
> > As if.
> >
> > A link interface is allocated an IP address and mask. That's state.
> > The link interface is either up or down. That's your immediate
> > connection to the subnet.
>
> Agreed. However, the state essentially disappears above IP. A
> properly implemented TCP neither knows nor cares about the state of
> interfaces.
I don't think that is reasonable. (And the whole pseudo-header design
shows the lack of clear separation between TCP and IP. They're in the
same stack, dammit)
> All it cares about is sending and receiving segments.
> These somehow either make their way to a remote destination or are
> lost.
>
> In particular, if you rip up TCP connections merely because an IP
> interface goes down, then that's a rather horrific bug. TCP is
> *supposed* to survive re-routes, whether in the local system or in an
> intermediate router.
If you're an endhost with only one link out (on a stick), ripping up
the TCP connections may be a reasonable thing to do. Why wait for
applications to time out and complain about something not being
reachable when they could simply learn 'no link available' and then
decide whether to communicate this to the user (a browser making http
requests, say) and decide whether to tear down their tcp sessions? The
decision to (half-)close TCP connections is an application decision,
so the application would need to know to make that decision.
(Not that this is IETF work, being an endhost interface thing.
However, any learned link characteristics that could be fed into a
smart TCP algorithm - a known long-delay link because you're at the
immediate end of a satellite hop affecting initial window size and
RTO, say - would be affected by that link going down. That's arguably
IETF work.)
> > > what would IP do with any particular information it gets?
> >
> > Pass it on.
>
> To whom? Such changes affect the IP forwarding ("routing") table in
> most cases, and need to be communicated to routing protocols. If you
> do QoS, then changes might affect any int-serv reservations you have,
> but that's really just a special case of a routing protocol.
>
> Such a change should *not* touch any transports or applications,
> however.
see above.
> > > There is no way to push information through a stateless system into a
> > > stateful one (e.g., TCP, or to application layers, e.g., routing
> > > protocols or user applications that are carried as data inside transport
> > > protocols).
> >
> > You're saying that if a link goes down there's no way to tell routing
> > about it, because IP gets in the way and routing is above IP?
> > (Fortunately, routers that know about links and know about routing
> > tables can use the information regardless if it's useful.)
>
> Agreed. Only routing can care.
>
> > When the link on a host goes down, will the TCP stack continue to
> > accept data from the application even though it can't be sent? (Phil's
> > kick-TCP-when-the-link-comes-up also springs to mind.)
>
> In short: *YES!*
>
> There are many reasons this is true. The link it was once using might
> not be the only way to get to the desired destination. Even if it's
> the only way to get there, the link may still come back soon enough to
> recover.
But can the application learn that passing data to TCP might not be
the best thing to do if connectivity is not there? TCP was designed
for an always-connected world, not a world of intermittent link
connectivity.
> If this weren't the case, then wouldn't you also want to kill off TCP
> sessions when you see a single ICMP Destination Unreachable?
I think you can trust local link interface state more than you can
trust ICMP messages generated remotely, and that the local TCP should
know which local interface(s), if any, that it's going out of.
> What's
> the difference between a link that flaps on an intermediate bottleneck
> router versus one that flaps on the local host?
Quite a lot. You *know* the local interface is flapping. If IP can see
the local interface is flapping, then L2 'debounce' timers have
already given up on it, and you can use that information.
L.
> If you are stuck using a stack that does otherwise, then that stack is
> just plain broken. You probably should upgrade to one that works
> right.
>
> --
> James Carlson, Solaris Networking <james.d.carlson@east.sun.com>
> 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
> pilc@ietf.org
> https://www1.ietf.org/mailman/listinfo/pilc
> http://www.ietf.org/html.charters/pilc-charter.html
> http://pilc.grc.nasa.gov/
>
<http://www.ee.surrey.ac.uk/Personal/L.Wood/><L.Wood@surrey.ac.uk>
_______________________________________________
pilc mailing list
pilc@ietf.org
https://www1.ietf.org/mailman/listinfo/pilc
http://www.ietf.org/html.charters/pilc-charter.html
http://pilc.grc.nasa.gov/
This archive was generated by hypermail 2b29 : Mon Jul 08 2002 - 08:17:04 EDT