Other Directory Sites: SeekWonder | Directory Owners Forum
The following archive was created by hippie-mail 7.98617-22 on Sat Apr 10 1999 - 01:10:59
Julian Assange (proff@iq.org)
19 Aug 1998 15:14:08 +1000
"Perry E. Metzger" <perry@piermont.com> writes:
> > and unimaginable round-trip times (10000 ms) to some servers (due to low
> > bandwidth and poor routing).
>
> Tossing UDP into such a network is likely to make it worse. You
> probably are in a situation where the only actual solution is
> increasing local bandwidth. At least TCP will back off in such a
> situation, preventing total network collapse.
>
> TCP with SACK might help a bit in such conditions, of course.
>
> Perry
I designed/implemented a secure (dh/dsa/3des) windowed udp protocol
(aka `sudp') with 4Gb windows, fast-start, backoff, etc,
and... SACKs. The protocol is designed to be highly fault tolerant,
and continue shoving data from one point to another under the most
adverse conditions (i.e active attacks against the protocol layer
itself including all sorts of computational and state exhaustion
denial of service attacks). I had great hope for SACKs, but found that
in the end, they were struggling to justify the huge increase in code
complexity. Decent TCP implementations (e.g 4.4bsd) do a fairly good
job of inferring SACKs without having any SACK information in the TCP
header. If you have good statistics about RTT, and start noticing a
lack of ACKs or dulicate ACKs it isn't too hard to back out which
packet was most likely to have been dropped and act accordingly (i.e
fast retransmit). This doesn't work as well when you have massive
packet loss and very large windows. Real SACKs are more efficient
here, not in terms of getting the data through, but in terms of NOT
retransmitting more than you need to. Why not simply use TCP+SSL then?
Because while SSL provides content security, it doesn't provide
protocol integrity.
Cheers,
Julian.
The following archive was created by hippie-mail 7.98617-22 on Sat Apr 10 1999 - 01:10:59