lkml.org 
[lkml]   [2002]   [Mar]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: PPP feature request (Tx queue len + close)
Jean Tourrilhes writes:
> If what you say is true, I should *increase* the buffering
> below PPP to make sure that packet don't get dropped above PPP.

No. Decreasing the buffering below PPP is the right path. 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.

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).

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. Anything that
you do that breaks these assumptions is probably the wrong thing to
do. Think "packets" not "streams" below PPP.

http://www.ietf.org/internet-drafts/draft-ietf-pilc-link-arq-issues-03.txt
http://www.ietf.org/rfc/rfc3150.txt
http://www.ietf.org/rfc/rfc3155.txt

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

\
 
 \ /
  Last update: 2005-03-22 13:24    [W:0.108 / U:0.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site