Re: Melting the Internet?

Richard Cogger (
Wed, 3 May 1995 12:38:22 -0400

Once again, proposals to use tcp for A/V... see below:

At 11:02 AM 5/3/95, Sean Foderaro wrote:
> CU-SeeMe may be the *most* Internet *unfriendly* application to ever
>be widely distributed. (Of course that wasn't the intention).
> Why?
> The tcp/ip protocol suite contains two transmission protocols:
> tcp - reliable, flow-controlled
> udp - unreliable, no flow control
> CU-SeeMe chose udp for the video, figuring that it didn't really
>matter if a frame got lost in transmission.
Not only doesn't it matter, a retransmission would waste bw, since the
retransmitted piece would be too late to be useful; time keeps goin' on.

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

Yes, nv, vat, vic, wb, nevot, etc. all the A/V stuff for the mbone; Apple
QTC; no doubt anything with any realtime or pseudo realtime requirement. A
soon to be release version will let you set a receive-cap, which senders
and reflectors will honor, so you can keep from flooding your ppp server.
> 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.
Exactly right. On a point-to-point connection, the adaptation seems to
work fairly well unless someone cranks up the minimum cap. The new
version, including new code in the reflector will customize bw use per
recipient, and should work a lot better.

> I think that the CU-SeeMe team (plus whoever gets access to the
>source) should work first at making the program Internet Friendly.
We are.

>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).
No. Completely inappropriate. TCP error recovery would be useless and
detrimental. Yes, the app should compete (relatively) fairly with tcp
streams, and we intend to work toward that. Also, as IP mcast becomes more
available, we will want to use that to increase efficiency greatly
(eliminate redundant streams), and end-to-end error control and flow
control as tcp does it is not appropriate in a mcast environment. For
reliable one-to-many transport, check out the documents on the CU-SeeMe
AuxData transport that are on the usual ftp server.

>If that isn't possible, then do extremely aggressive flow control
>(both in the cu-seeme application and in the reflectors).
>When the application is downloaded it should have the cap set
>at, perhaps, 0.5 fps. Setting it higher would require that you be able
>to find the appropriate dialog box. When you tried to set it higher
>you would get a warning describing the amount of network bandwidth
>required for the transmission so you can decide if you really want to
>use that much network bandwidth (and whether your net connection can
>support it).

I think more obvious warnings about large reported loss rates would be a
better approach, in combination with the reflector and app improvements
described above. Both the app and the reflector will also observe what
bandwidth appears to be available and act accordingly, but this needs to be
more of less automatic. The general notion of warning messages when a user
tries to do something to override network-protective sensible automatic
operation would be a good one. And the cap to work with is Kbps rather
than fps, since the network doesn't care about frames.

Cheers, -Dick