From: Kragen Sitaker (kragen@pobox.com)
Date: Wed May 09 2001 - 11:55:08 PDT
Harvey Newstrom writes:
> [quoting Kragen without attribution]
> > 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.
That's a well-written TCP implementation, not a well-written TCP
application; this is called fast retransmit and rapid recovery. Even
fairly poorly-written TCPs do this these days (after all, Jacobson and
Karels's paper that describes fast retransmit and rapid recovery was
presented at SIGCOMM '88), but rapid recovery only works for the loss
of an individual packet. In any event, applications running on top of
that TCP implementation generally see a delay in their data ---
although the kernel is receiving the data after the dropped packet, it
doesn't hand it to the application until the dropped packet is
re-sent.
So, yeah, data delay does occur, even though it doesn't slow things
down. Bulk data transfer TCP applications don't care, but
latency-sensitive ones like telnet do.
> What you describe only occurs when using UPD with live transmissions such as
You mean UDP, not UPD, and you mean "isochronous", not "live". And it
doesn't occur with UDP --- that's the whole point of UDP. That's what
this paragraph from my original post was about:
If you're transmitting streaming video or audio, it's OK if
some packets get lost. Your users will be irritated, but
they'll still use it; the Bellheads will still laugh at you and
point out that they can offer better QoS, but you're still
providing voice service at roughly 1/20 what they charge for
it, so you don't care. So you just use UDP and forget the damn
dropped packets.
> audio or video. Buffering the audio or video should allow these minor
> packet losses to be recovered without any delay to the user.
Buffering is acceptable in cases where timeliness of the data is not an
issue --- generally, when it's not "live" in the usual sense of the
term as applied to audio and video feeds. It really sucks for Speak
Freely conversations, though.
> 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.
You seem to have reinvented the ideas in the rest of the post without
bothering to read it. I guess that means I did a good job of leading
up to them in the first part of the post.
> 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.
That's what this section of the original post was about:
assuming independent 5% packet loss on both connections. (An
erroneous assumption, but I'll get to that later if I have
time.)
I didn't have time.
> 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.
You haven't written or managed much software development or other
engineering, have you? :)
--
<kragen@pobox.com> Kragen Sitaker <http://www.pobox.com/~kragen/>
Isochronous to all of us are the devices of an art deeper than we possess
ourselves.
-- Gandalf the Isochronous [J.R.R. Tolkien, "The Two Towers"]
This archive was generated by hypermail 2b29 : Wed May 09 2001 - 12:00:09 PDT