Alan Cox wrote:
>
>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=20
>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 se=
nds
>frame 3 again immediately, then will get an ack of 7 and continue.
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 pa=
cket
boundaries.
If more than one packet in that sequence is missing, fast retransmit fa=
ils
-- 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 giv=
e
you one round trip time total.
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 se=
nd
big files). IMHO, selective reject would increase that number somewhat.
--=20
In 1882 the first pilots license was issued. It was made of flypaper.
-- "On This Day in History"
--=20
Matthias Urlichs \ XLink-POP N=FCrnberg | EMail: urlichs@smurf.=
noris.de
Schleiermacherstra=DFe 12 \ Unix+Linux+Mac | Phone: ...please use =
email.
90491 N=FCrnberg (Germany) \ Consulting+Networking+Programming+etc'i=
ng 42
PGP: 1B 89 E2 1C 43 EA 80 44 15 D2 29 CF C6 C7 E0 DE=20
Click <A HREF=3D"http://smurf.noris.de/~smurf/finger">here</A>.