Moreover, fast retransmit only works if you _get_ these three acks. If =
you
are telnetting and lose the packet with the next-to-last character,
there'll be a timeout instead: you lose.
Selective reject would actually reduce the number of packets exchanged =
in a
lossy situation, which is a Very Good Thing because the line is overloa=
ded
already (assuming the packets are dropped because a router's queue has
indigestion) and these retransmits of data which have arrived intact ar=
en't
going to improve the situation.
> > The rule of thumb seems to be that with more than about 10..25% pac=
ket
> > loss, TCP just doesn't work very well (or not at all, if you want t=
o send
> > big files). IMHO, selective reject would increase that number somew=
hat.
>=20
> Ask a mathematician. Certainly at 40% loss tcp becomes a bit of a jok=
e.
>=20
The problem is that the acceptable packet loss gets smaller as the wind=
ow
size grows. Which is why telnet across such a line is slow but basicall=
y
works, while ftp is more or less unusable.=20
There are of course way to get data across almost any connection. TCP i=
s
not the best protocol to do that (of course). However, that's no reason=
not
to increase the limit if we can do so, and the overloaded and lossy
lines of some providers out there seem to be reason enough.
Selective reject does seem to be a sensible way to do that.
--=20
The Cabinet is a pig, a serpent, a tiger and an ox brought together and
told to produce offspring.
-- New York Times, Jan. 20, 1981
--=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>.