[2468] in linux-net channel archive
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