[2146] in linux-net channel archive
Re: IP: optimize as a router not host
daemon@ATHENA.MIT.EDU (Alan Cox)
Tue Mar 19 06:30:02 1996
From: Alan Cox <alan@cymru.net>
To: smurf@smurf.noris.de (Matthias Urlichs)
Date: Tue, 19 Mar 1996 11:10:23 +0000 (GMT)
Cc: alan@cymru.net, smurf@smurf.noris.de, linux-kernel@vger.rutgers.edu,
linux-net@vger.rutgers.edu
In-Reply-To: <96Mar19.113815+0100met_dst.2186-117+11@work.smurf.noris.de> from "Matthias Urlichs" at Mar 19, 96 11:38:04 am
> Umm, yes of course. But selective reject still has advantages. For
> instance, the receiver can tell the sender which range(s) of bytes it's
> missing, whereas with fast retransmit the sender has to remember the packet
> boundaries.
The sender already knows these as it has the packets handy for
retransmission. The BSD one simply spots 3 repeated ack values in a row
and uses that.
> If more than one packet in that sequence is missing, fast retransmit fails
> -- you don't know which packet got lost, you have to wait for the ack, i.e.
> at least one round trip delay for each hole. Selective reject would give
> you one round trip time total.
Quite probably.
> The rule of thumb seems to be that with more than about 10..25% packet
> loss, TCP just doesn't work very well (or not at all, if you want to send
> big files). IMHO, selective reject would increase that number somewhat.
Ask a mathematician. Certainly at 40% loss tcp becomes a bit of a joke.
Alan
