[2144] in linux-net channel archive
Re: IP: optimize as a router not host
daemon@ATHENA.MIT.EDU (Alan Cox)
Tue Mar 19 05:15:21 1996
From: Alan Cox <alan@cymru.net>
To: smurf@smurf.noris.de (Matthias Urlichs)
Date: Tue, 19 Mar 1996 09:58:39 +0000 (GMT)
Cc: linux-kernel@vger.rutgers.edu, linux-net@vger.rutgers.edu
In-Reply-To: <96Mar18.210800+0100met_dst.2186-117+3@work.smurf.noris.de> from "Matthias Urlichs" at Mar 18, 96 09:07:57 pm
> Rogier Wolff <r.e.wolff@et.tudelft.nl> writes:
> >
> > Suppose a sender sends packets 1,2,3,4 and 5. At the recieving end
> > you get 1,2,4,5. What you do is you ack that you got packet 1 and two.
> > When you get 4 and 5 you ack that you got 2 again and again. When a
> > sender gets these it is supposed to conclude that packet 3 got lost
> > and try resending that.
> >
> There is a RFC which implements selective reject -- i.e., in the ack, you
> add some TCP options which tell the sender that you do have packets 4 and 5
> (or rather, the sequence numbers for which 4 and 5 contained data).
The selective ack RFC never went anywhere because you can use a scheme
known as fast retransmit instead to avoid pipeline stalls on a loss of
1 frame/window or less. What happens is the sender sends 1 2 3 4 5 6
the receive gets 1 2 4 5 6. The acks from the receiver thus go
1 2 2 2 2 .. seeing 3 acks for an old frame in a row the sender now sends
frame 3 again immediately, then will get an ack of 7 and continue.
Alan
