Jean Tourrilhes writes:
> > No. Decreasing the buffering below PPP is the right path.
>
> Yes, that's what I want to do it. But with regards to TCP,
> there is no difference if packets are buffered within PPP or below
> PPP. So, reducing buffering in PPP is also a win.
True. Actually, except for MP reassembly, there should be *no*
buffering in PPP at all. If there is on your platform (I'm much more
familiar with Solaris than with Linux), then that's certainly an odd
design problem.
I've seen the deep buffering problem before in other contexts: older
BSD stacks had all output ifq_len values set to 50, even if the links
were really slow (<9600bps), and this often triggered retransmits.
TCP congestion detection *depends* on packet loss. Loss is a good
thing.
> > Running one retransmit-based reliable protocol atop another is usually
> > a recipe for disaster (as you've found; as others have found by trying
> > to run PPP over TELNET over the general Internet).
>
> Not true. It all depend of the timeframe of those
> retransmissions, and how they are triggered. That's why TCP works
> properly on 802.11b. Of course, this assume that the link
> retransmissions are designed properly.
That's still exactly what I said in that message, just restated a
different way:
In general, if you have link-layer ARQ, you need to have the
time constant be *much* shorter than any RTT estimate that TCP
is likely to see, or you get oscillatory behavior out of TCP.
In other words, link layer ARQ should be minimally persistent and done
only if the retransmit interval is much shorter than TCP's RTT
estimate. If it's not, then you have a controlled disaster. This has
been demonstrated before with PPP-over-TCP hacks.
> > The transport layer (most often TCP) assumes that the network layer
> > (IP) has minimal (and slowly varying) latency, but is lossy, and thus
> > that it has minimal buffering and little error control.
>
> Not true. Try running TCP on links with 20% packet losses.
> Also, any ethernet driver flow control the stack through
> netif_stop/start_queue() to avoid local overruns.
I said "lossy," not "high error rate." There's quite a difference
between the two. TCP finds the one (by definition) bottleneck in the
path by finding the point where packets drop and optimizing around
that. It just won't do that if there aren't losses, and the window
will open until the link-layer queue becomes a serious stability
problem.
(If the link can push back in Linux with local flow control, then the
question becomes: why doesn't that work with this application? Is
something missing from the IrDA interface or the PPP kernel bits that
prevent this from working right? And if it's the latter, why don't
regular serial users see the problem?)
(You can do better by dropping packets *earlier* -- see RED.)
> Already read those. Guess what, my name is event in the
> acknowledgments ! How bizzare ;-)
*Blush* I somehow forgot about your postings among the flood of draft
updates from Phil and odd flame-wars. :-/
-- James Carlson <carlson@workingcode.com> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Mar 07 2002 - 21:00:47 EST