networking

From: Harvey Newstrom (mail@HarveyNewstrom.com)
Date: Wed May 02 2001 - 07:39:37 PDT


> Date: Thu, 26 Apr 2001 03:25:33 -0400 (EDT)
> From: Kragen Sitaker <kragen@pobox.com>
> To: fork@xent.com
> Subject: networking
>
> TCP is nice, except that it has the unfortunate property that a single
> lost packet can stall the entire stream behind it until that packet is
> retransmitted. This is particularly bad for IP-over-TCP tunneling.
>
> Suppose you take a different tack. Instead of transmitting the data
> over UDP, you transmit two copies of it over two parallel TCP
> connections. You're using twice the bandwidth you were before, but the
> other end now only has to deal with stalls 0.25% of the MTUs ---
> assuming independent 5% packet loss on both connections. (An erroneous
> assumption, but I'll get to that later if I have time.) The recipient
> just uses whichever data they receive first.

Actually, a well-written TCP application does NOT stall when a packet is
lost. It continues to assemble all the packets as they come in. It sends a
request for the lost packet, but other packet transmissions continue at the
normal rate. When the replacement packet comes in, it is inserted in its
proper place. No data slowdown should occur.

What you describe only occurs when using UPD with live transmissions such as
audio or video. Buffering the audio or video should allow these minor
packet losses to be recovered without any delay to the user.

If you do want to send redundant data, there is a better technique than
sending duplicate streams. Send checksum codes for data corrections. Minor
corrections can be made based on the checksums without having to resend
data. Only larger and multiple instances of data loss would cause a resend
to occur.

Sending two duplicate streams might not solve packet loss. If such loss is
caused by an intermediate device, static on the lines, malformed data on the
sender or a brief inability to process by the receiver, it could easily
cause the same loss in both data streams at the same time. This is
especially true if they both are being sent at the same time to provide live
throughput.

Your idea is very creative and thoughtful, however. Once you have the seed
of an idea like this, working out the bugs and extrapolating to a better
implementation is minor. The hard part, having the first idea in the first
place, is already done. Even though I pointed out some problems with your
suggestion, I highly commend your creativity in addressing the problem.
This is where million dollar inventions or history-changing ideas come from!

--
Harvey Newstrom <http://HarveyNewstrom.com> <http://Newstaff.com>



This archive was generated by hypermail 2b29 : Sun May 06 2001 - 08:04:36 PDT