Re: PPP feature request (Tx queue len + close)

[Jean Tourrilhes <jt@bougret.hpl.hp.com>]

On Tue, Mar 05, 2002 at 02:15:59PM -0500, James Carlson wrote:
> 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.

	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.

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

	Yep.

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

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

>  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

	Already read those. Guess what, my name is event in the
acknowledgments ! How bizzare ;-)

> James Carlson

	Jean