Speed negotiation between Reflector and CU-Seeme

Bart Kindt (bart@dunedin.es.co.nz)
Tue, 24 Jan 1995 02:51:00 -0500


On the Wish-List this should be on top (:-):

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.
It is almost an inresponsible situation that when a CU-Seeme program
connects to a Reflector, a *unknown* (and often massive) data stream is
unleashed, with multiple windows opening all by themselves (another serious
flaw) and each open CU-Seeme window simply dumping up to 80 kbps into the
receiver's backbone(s).

For example: Here in Dunedin, New Zealand we have the following situation:

USA <> Waikato, New Zealand = 640 kbps
Waikato <> Dunedin = 128 kbps
Dunedin <> My Site = 28,800 bps (+ compression)

If I connect to Cornell Reflector, all by itself multiple windows open, and
a data stream of probably hundreds of kbps is poured into the 640 kbps
International link, then the 128 kbps national link (which probably will
fill up completely) and then only about 35 kbps of mixed up packets finally
reach my computer.
This is ridiculess, causes havoc on our national links.

I am aware the program was never designed to be used in this condition; but
I think the fact is that it *is* used like this by many people.

I think it is time a protocol is worked out, so that a maximum speed is
negotiated between the Reflector and the receiving CU-Seeme, *before* any
video is transmitted. The maximum speed can be set in CU-Seeme, just as it
is now done for transmitting Video.

Let me go brainstorming for a moment, I am not sure what is possible and
what not:

It would even be possible to automatically *adjust* transmission speeds on
the fly, when the receiving end finds that it only receives for example an
average of 20 kbps, and after say a minute sends a command to the Reflector
(or other CU-Seeme) to drop the transmision speed on that side to that level.
This way, even if users have no idea what they are doing with the CU-Seeme
Setup, the dataflow is automatically reduced to what the link can handle.

The Relector should keep a complete "picture" in memory of the transmitting
CU-Seeme (which may me transmitting a 80 kbps), and the Reflector should
send a 'snapshot' of this picture to the receiving CU-Seeme which may be
receiving at only 14 kbps.

This way, the slow-receiving CU-Seeme would still get a more or less correct
update of the picture, because it gets it from the updated 'copy' in the
Reflector. It does *not* get some bits and pieces forwarded directly from
the transmitting CU-Seeme, in which case you will always have a 'mixed up'
picture because to many updates will never reach it.
This is what happens now ofcourse. If I connect to NASA TV, the resulting
picture is a mixture of at least 5 completely different frames...

So guys, what do you think: can this be done?

If above wild ideas could be incorporated, this would solve all dangers of
CU-Seeme clogging up the links in the world, and it would be pretty save to
let in-experienced users loose on the program.

Three things which should urgently be fixed in the Windows version:
- Do NOT open incoming Video Windows automatically!! Let the User decide.
This will solve complete overflooding of the link because people come and go
on the Reflector, and new Windows pop open all the time.

- Do NOT automatically *open a connection* only because video packets are
coming in. This would solve the problem of not be able to *close* the
connection, because it re-opens again all by itself a few seconds later.

- Fix the window selection list...

My two cents worth. Hey, I really do appreciate the great efforts which have
gone into this program!

Cheers, Bart.
-----------------------------------------------------
Bart Kindt (ZL4FOX), Sysop, Efficient Software NZ LTD
-----------------------------------------------------