Re: Melting the Internet?

John D. Lauer (
Wed, 3 May 1995 13:16:25 -0400

OK, this might interest some of you. This is the latest internet traffic
report. As you can see "other TCP/UDP", which is ports other than 0-1023,
2049, 6000-6003 and 6667, is ranked number 2 in terms of traffic generated.
CuSeeMe could be a big player in this but you can't tell for sure from the
data. So I sent a message to Merit asking them to take a look at their
database for UDP port 10048 and 7648. Hopefully they will respond with an
answer so we can all see just how much bandwidth CuSeeMe uses.

<NIC.MERIT.EDU> /nsfnet/statistics/1995/nsf-9503.highlights

NSFNET Backbone Traffic Distribution by Service

March 1995

Packet Total: 88,497,052,300

Byte Total: 20,239,988,701,200

Service Name Port Packet Count % Pkts Byte Count % Byts
============ ==== ============ ====== ============= ======
www 80 16880373100 19.075 4833271270950 23.880
(other_tcp/udp) -999 15608428950 17.637 3143001086100 15.529
ftp-data 20 13869566100 15.672 4898203038300 24.201
telnet 23 7347386400 8.302 596006936550 2.945
nntp 119 7177207050 8.110 1683707014200 8.319
smtp 25 6228147200 7.038 1000861707300 4.945
ip -4 5444825900 6.153 1704644586650 8.422
domain 53 4355316300 4.921 453140710200 2.239
irc 6667 2165553000 2.447 264637445500 1.307
gopher 70 1734408900 1.960 496925911550 2.455
icmp -1 1649076250 1.863 127051123050 0.628
ftp 21 1427247950 1.613 100463313750 0.496
unidata-ldm 388 498679750 0.563 153553668500 0.759
X0 6000 377145700 0.426 64822021550 0.320
finger 79 364442250 0.412 22594763100 0.112
vmnet 175 234402350 0.265 98476865350

> CU-SeeMe may be the *most* Internet *unfriendly* application to ever
>be widely distributed. (Of course that wasn't the intention).

In terms of CuSeeMe being the *most* Internet *unfriendly* application to
ever be widely distributed, I doubt it. There is nothing wrong with using
UDP on the internet. In fact UDP reduces the data flow because it doesn't
need the overhead for reliable, flow-controlled communications. Also TCP
needs a one to one connection b/w the client-server which means you can't do
multicasting. You can do multicasting using UDP. Multicasting puts even
less traffic on the network because it sends out one packet of data with a
bunch of addresses tacked onto the front. If TCP were used a copy of the
data would have to be sent out for each address. This would also put a much
greater load on the reflector.

>Two problems with this:
> 1. udp is rarely used on long haul transmissions. (Can anyone name
> another other program that tries to send large amounts of data
> over the internet using udp?) As a result there are probably
> bugs in the udp packet overflow code in many versions of
> tcp/ip. [If we have link quality monitoring enabled on our
> ppp connection then when CU-SeeMe run our ppp connection drops
> because the Link Quality Monitoring packets can't get through]

Frames can still get lost in a TCP transmission. Its just that the protocol
fixes it and makes it look as if this never happened to the user. The
internet was designed as an unreliable network. So whether TCP or UDP is
being used on a long haul transmission is irrelevant. The same amount of
packets would be lost. The protocol doesn't change the physical nature of
the network. Most people want an identical copy of data when they transfer
it across the 'net that's why you don't hear a lot about UDP. That's what
gives CuSeeMe its advantage. It doesn't need every bit of data to function.

> 2. It means that the application must do flow control.
> I think that CU-SeeMe tries to do this via packet loss reports.
> I don't know the details but I wouldn't be surprised if
> packet loss reports get lost themselves when the network
> buffers are full of udp video packets.

CuSeeMe's method of flow-control is to receive as much data as it can.
Whatever it doesn't get it doesn't worry about. 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.

>Ideally the tcp protocol would be used throughout. That way you
>compete fairly for network bandwidth with people doing other
>important things (such as downloading Dilbert).

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

John D. Lauer
Medical Center Information Technology
University of Michigan