Re: Melting the Internet?

Sean Foderaro (jkf@frisky.Franz.COM)
Wed, 03 May 95 12:38:34 -0700

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
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?
Basically this is flow control in action and flow control is a good

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
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.

One could design a system using UDP that let the sender know
what had to be retransmitted, basically duplicating those pieces
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.

Q. Uh, how is it that UDP gives a CuSeeMe user unfair advantage over any other
TCP internet user?

A. Imagine that you've got a 10 inch water pipe (representing a
10mbps network) connected to a 5 inch pipe (representing a
1 mbps net connection) connected to a garden hose (representing my
little 14.4kbps connection)
[obviously the scale is off but that doesn't matter].

Now you start to send me water (represening UDP packets) at a huge rate.
Water will start to flow out of the garden hose but not fast
enough so the 5 inch pipe will fill up and then the 10 inch
pipe will fill up. Soon the pressure valves on the pipes
will open up and water will spray out (representing packets being

So while I'm still getting data through my garden pipe at 14.4kbps
you've managed to congest the whole network preventing other people
from using it.

Now let's use TCP rather than UDP in the scenario: With TCP you
start sending water though the pipe for a few seconds but stop
until I tell you that I've received the first part of it
then you send some more. When we reach a steady-state
the amount of water flowing
through the 10 inch pipe is the same as the amount going though
the 5 inch pipe which is the same as the amount going through
the garden hose. So there is plenty of space in the 10 inch and
5 inch pipes for other people to send their water.
This is what I meant by being fair to other TCP users.

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.

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