Re: Speed negotiation between Reflector and CU-Seeme

Alan Larson (
Tue, 24 Jan 1995 12:55:15 -0500

Bart Kindt wrote:
> Any CU-Seeme program should negotiate the maximum data flow when connecting
> to a Reflector (or another CU-seeme for that matter).
> Reason? The CU-Seeme on the *receiving* end is the one who knows how much
> load the backbone can have.

This is not quite true. It is true in the example given, but the real
world can be much more complex. For example: My machine is connected to
an ethernet, which goes (via a couple of routers) to a serial line running
about 48 kbps to a remote office, where it is coupled to an ethernet.

Thus, the machines at each end think the bandwidth is Ethernet speed.
The real bandwidth is substantially less, since the link in between is
hidden from them. The real bandwidth AVAILIABLE on that link is very
likely substantially less than the bandwidth of that link, since the
serial link to the remote office is very likely to be busy.

The problem is that CU-SeeMe has no congestion control, and will quite
gladly blast the network with all it feels that it needs to send, allowing
for high lost packet rates. The data rate does not adapt to the currently
available bandwidth.

The situation is probably not as simple as switching to TCP (which can
deal with the congestion control using the Van Jacobson algorithms). TCP
will deliver the data reliably, but if the data needs retransmission, it
makes more sense to transmit current data instead of saved data.

The reflectors need to rate adapt between clients of different speeds --
simply throwing away packets from a fast source when sending to a slow
receiver will simply result in fairly unusable transmission -- it really
needs to understand which packets to throw away.

I have been waiting for the sources to be available, as I hope to demonstrate
better algorithms that I have worked out, including one (possibly) new concept.