Re: Melting the Internet?

Richard Cogger (R.Cogger@cornell.edu)
Wed, 3 May 1995 18:05:50 -0400


One more time:

At 3:38 PM 5/3/95, Sean Foderaro wrote:
> I received a number of replies to my message, some private and some to
>the mailing list. I'll address the main items brought up:
>
>Q. TCP is bad since it does packet retransmission (if necessary), and
> why retransmit old data?
>
>A. If TCP has to resort to retransmission then it is because the
> network dropped the packet (or acknowledgement), which means that
> the net can't support your packet rate at this time. The net

Correct. However, you should be aware that tcp keeps sending faster and
faster until a packet is lost. It then retransmits that one, slows down,
and starts speeding up again, repeating indefinitely as long as there is
data to send. Since (almost) all tcp's do this, they are all continuously
feeling out the capacity of the network and sharing it. BUT, a sending tcp
does not know about a lost packet until a full round-trip from end to end
(also assuming the ack doesn't get lost).

> is telling you to slow down. If you were sending UDP packets they
> would likely get dropped too. What is worse, retranmitting an old
> packet or sending a new one that will get dropped anyway?

If a packet is lost, say half way to the destination, then tcp will
continue sending (and speeding up actually) for the portion of the
delay-bandwidth product equal to the rest of the trip to the destination
(for the next packet that *doesn't* get lost), plus the return of the ack,
plus various processing overheads. If there are a dozen packets in flight,
a not-unusual circumstance with a good connection, and the congestion
causing the drop persists for a while, then tcp will have sent quite a few
packets to get dropped as well.

> Basically this is flow control in action and flow control is a good
> thing.
>
> The current CU-SeeMe using UDP doesn't know whether a packet reached
> its destination or not so it is doing continuous retransmission of
> unchanged parts of the video image. Of course it does this at

Actually, the current CU-SeeMe sender code will hear in an average of 2.5
seconds plus fraction of RT time that packets have been lost. If the
overall average loss is greater than 5%, it will slow down. This is not
quite as responsive as tcp, but it also doesn't hunt up as fast either. If
a tcp is increasing for an average of 20 packets before slowing and
starting to hunt up again, it would be about equivalent, but I've no idea
what a typical loss percentage is for a tcp cycling up and down. My guess
is it depends on many things. So, CU-SeeMe either point-to-point or
multiparty with similarly bandwidth'ed participants will function not all
that differently from a set of tcp streams.

> a slower rate. If TCP were used then these background
> retransmissions would be totally unnecessary.
>
> So the situation is:
> tcp - retranmission when you're sending faster than the net can
> handle at this moment.
> udp - continuous retransmission at a low rate.

The "aging" mechanism to retransmit unchanged squares is really a low (1%
or so) background thing. The problem with tcp's retransmission is that, in
a realtime application, it is totally useless, and worse, while waiting for
old stuff to come in on retransmission, new stuff is held back from the app
(so it too becomes old) and will all just be thrown away when it finally
comes up the stack. To repeat: tcp is completely inappropriate for
realtime traffic.
>
> One could design a system using UDP that let the sender know
> what had to be retransmitted, basically duplicating those pieces

Not duplicating, solving a different problem.

> of TCP that are appropriate to real-time data transmission
> (such as packet acknowledgement and flow control). It appears
> that that is what is happening at CU. I certainly support that.
> Once that work is *done* I'd support using UDP for transmission.
> Until the point that that software is working, it is my
> humble opinion that the version of CU-SeeMe freely available to
> the folks on the internet should use the sub-optimal TCP protocol.
> That way people who don't know what they are doing don't hurt
> themselves or others.

If you would like to try getting video/audio to work with tcp, be my guest.
Long before you could (you couldn't, imho) we will have the improvements
in to deal with the problem of differently bandwidth'ed participants trying
to conference together.
>
>
>Q. Uh, how is it that UDP gives a CuSeeMe user unfair advantage over any other
> TCP internet user?

If an application just pushes UDP packets out with no flow control, all the
polite tcp's will get elbowed out of the way. If anyone has any data on
what loss rates tcp typically runs at, as it cycles up and down, that would
be very useful to us. We will try to make CU-SeeMe approximately as polite
as tcp.
>
>Q. what about this following statement?
> So if you're on a slow PPP
> connection, the reflector could be sending you an
> 80 kbps stream and you'd only get about 23 kpbs
> on a 28.8 connection. The rest of the data just expires
> once its TTL (time-to-live) is up.
>
>
>A. As my scenario above described, what would happen is that the
> data would get stuck in the memory of the machine responsible
> for forwarding the packets from the fast network (that can support
> the 80kbps) to the slow network (the 28.8 connection).
> After the memory filled up further incoming ip packets would simply be
> dropped. The packets in the forwarding machine's memory
> would never expire due to the TTL field. That field exists only
> to prevent router loops and is decremented each time a packet
> is forwarded, it has no relation to wall clock time.
>
> The effect is that newer incoming video frames will be dropped by the
> forwarding machine while it slowly delivers old video frames
> that are already in its memory.
>
Correct. Just why we're doing what we are for the next release: the
problem of unbalanced participants.

>
>Q. You can't do TCP multicasting.
>
>A. Agreed. Multicasting is a good thing and is internet-friendly.
> If CU-SeeMe only worked for people connected to the multicasting
> backbone it would cut out a lot of users (like me for example)
> but it would be much kinder to the internet.
>
> My statement about CU-SeeMe being internet unfriendly only applied
> to the current version (since it was this version that people
> expressed concern about publicizing via a Usenet group).
> I believe that the folks at CU *will* come up with a version that
> is internet-friendly
>
We're talking about a couple weeks till the next version, with a little
luck. Probably take that long to get set up with Usenet anyway.

Cheers, -Dick