Lloyd Wood writes:
> On Wed, 10 Jul 2002, Vernon Schryver wrote:
> > since I wasn't talking about Linux, and since the common BSD
> > `routed` does not run on Linux (for lack of 4.4BSD-Lite "routing
> > sockets"), I don't see its relevance.
>
> (Linux has netlink these days.)
>
> Right. routing sockets aren't common, so may as well be chopped liver.
Even if that were true (and I certainly don't think that it is), how
could internal interface details be relevant here?
The IETF writes Internet protocols, not internal APIs. There are
other groups that are focussed on that problem.
Besides, if you're really using a broken system that doesn't have
routing sockets or any other usable interfaces, then why not just tell
the vendor that you're switching to a system that *does* support the
interfaces you need? I happen to have direct knowledge of at least
one such system that's available. ;-}
> > On the other hand even 90 seconds is faster you can reasonably hope
> > to do anything with an existing TCP/IP connection no matter how many
> > L2 triggers you have, because no L2 trigger on your laptop is going
> > affect the far end of a TCP connection.
>
> It doesn't need to. It only needs to affect the near end, so that
> it's known that sending out a packet and waiting for a response is a
> waste of time and the application(s) can go do something else instead.
Isn't it a waste of time for the remote end of the communication to
send data as well? Unless this is a fixed L2 connection between the
two endpoints, how does *it* know about the problem?
Why is it an interesting optimization to code for the special case
where one end of the TCP connection happens to be the one IP node that
is directly attached to a flakey L2? What happens when there's a
firewall/router used to terminate that L2 instead? Don't we just fall
back to the ICMP Destination Unreachable timeout case instead?
> An analogy: If you're gagged, don't waste your breath saying 'Mppph!
> Mppph!' and waiting for people to do what you say. Suppress it until
> the gag comes off and spend the time thinking about a compelling plea
> for your life instead.
Of course, if you're a computer, it does you no harm at all
periodically to say "Mppph" in the hope that one time it will work.
Computers seem to have a staggering amount of breath.
> > just as they assume that TCP never
> > before ran over modems slower than 9600 bit/sec with large error rates
> > or long drop-outs (e.g. the effects of "call waiting" or needing to
> > hang-up and redial).
>
> diddling those bits alone may not be sufficient, for reasons James
> points out. It's not widespread practice, and thanks to the rest of
> the OS and related assumptions it might not have the desired effect.
I don't agree with much of that at all. Diddling those bits works for
*most* of the interesting cases. In any event, what we're talking
about here is internal system architecture, not protocols.
For the cases where it *doesn't* work, some very L2-specific work
needs to go on, and (clearly) these need to be documented in detail
before any work directed at solving them can start.
Vernon Schryver writes:
> as has happened with the rest of the network API. (Does anyone still
> really support STREAMS, not to mention "QIOs" and other stuff?)
Yes, of course, SVID-compliant systems still support STREAMS. :-/
-- 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/
This archive was generated by hypermail 2b29 : Wed Jul 10 2002 - 11:02:08 EDT