[2468] in linux-net channel archive

home help back first fref pref prev next nref lref last post

Re: PPP is slow (and so is TCP!) [with fixes]

daemon@ATHENA.MIT.EDU (Alan Cox)
Fri Apr 12 12:18:26 1996

From: Alan Cox <alan@cymru.net>
To: schenk@rnode84.cs.toronto.edu (Eric Schenk)
Date: 	Fri, 12 Apr 1996 16:02:56 +0100 (BST)
Cc: linux-kernel@vger.rutgers.edu, linux-net@vger.rutgers.edu,
        iialan@iifeak.swan.ac.uk
In-Reply-To: <199604120652.CAA00272@rnode84.cs.toronto.edu> from "Eric Schenk" at Apr 12, 96 02:52:07 am

> send not send the next character until it gets the ack for the
> previous one. Since ACKs are delayed this really slows down
> the arrival of the response to interactively typed characters.
> Second, after I fixed the above problem I found that delayed ACKs
> where not being dealt with correctly. In particular we're
> violating RFC1122 in a couple of places:
> 
> o It is required that an ACK packet that is delayed be delayed
>   by no more than 0.5 seconds. The implementation can be forced
>   to violate this easily. The problem is that every time new data
>   arrives we reset the timeout for the ACK. An ACK can get delayed
>   for as long as we continue to received data packets in order.

Sounds like we have/had another serious oversight too. BSD doesnt delay
acks on frames that are not mss sized (to avoid tripping nagle). We ought
to be doing the same. I hadnt realised the changes that got put in didnt do
that



home help back first fref pref prev next nref lref last post