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:58
Berke Durak (berke@gsu.linux.org.tr)
Wed, 19 Aug 1998 00:34:27 +0300 (EEST)
On Tue, 18 Aug 1998, Perry E. Metzger wrote:
> You claimed that TCP is "painfully slow over long distance links" --
> it is, in fact, about as high performance as any protocol can be over
> such links, and it (in fact) is also as light weight as a protocol can
> generally be. It handles congestion control very well -- hand hacked
> algorithms in UDP are usually contributors to congestion, and are
> highly discouraged in an internet context.
> 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.
Thank you for your reply. I have just read the corresponding RFCs on SACK;
Turkey's network seems to fits somewhat in the described LFN model; when
transferring data using TCP there are often bursts of acceptable throughput,
which stop sporadically and restart only after a long timeout delay, which
seems to be too long (all this from observing the modem's RX/TX lights). I
just feel that the retransmission timeout is too long. Maybe I should not
blame TCP this way, especially when I have no background on the performance
of packet network protocols; do you have any references (preferably online)
regarding the "optimality" of TCP ? Probably requires deep statistical
analysis.
Anyway, from an egoistical point of view a "hand-hacked" packet-multiplying
UDP protocol should be useful, if only very few people used it: not for a
public protocol.
As for "normal", stream-oriented Internet applications (ftp, mail, web etc.)
SACK surely would improve performance on pathologic networks, but it has yet
to be implemented widely.
For the distributed chat, I still think a (carefully-designed, i.e. not
"hand-hacked") datagram-based protocol is more suitable; and for
transmitting datagrams, the obvious choice is UDP.
There is the "onion router" project, which is TCP-based, that allows
anonymous connections. However, for a distributed/cooperative chat protocol,
as users might join and leave quite frequently, and as response time
is very important, a connectionless protocol would be more suited.
Berke Durak - berke@gsu.linux.org.tr - http://gsu.linux.org.tr/kripto-tr/
PGP bits/keyID: 2047/F203A409 fingerprint: 44780515D0DC5FF1:BBE6C2EE0D1F56A1
The following archive was created by hippie-mail 7.98617-22 on Sat Apr 10 1999 - 01:10:58