Re: CuSeeme - NLnet-Transatlantic udp (7650) blocked

Dick Cogger (
Sat, 14 Jan 1995 14:59:38 -0500 (Ko Stoel) said:

>I mean; I pay for 28k8 Internet access. That routers have trouble
>forwarding a big stream of udp packets isn't my fault
>What 'handshake' is used ? Could it be possible that some sending CUSM node
>(Refector or client) with high enough bandwith did throthel up to much
>while little me just asks for 28k8 b/s.
>If so then there's a considerable chance Murphy's Law will apply :)
>You see; I still think 28k8 is an important bandwith (s/n ratio of analogue
>lines) At least my mother should (being 80) looking at the kids 300km away
Yes, well at its current level of development, CU-SeeMe lacks some refinement.
Each receiver sends a conference control message every few seconds,
detailing its own capabilities and status with an entry for each
participant it has had such a message from recently. In each of these
entries, the recent loss rate for video received from that source is
reported. Also, bits indicate if you want video (window is open), audio,
etc. from each source.
Senders add up all the loss reports and calculate the % of loss
overall. If it is more than 5%, the sender slows down, if less it speeds
up, both by adjusting the cap between the user set max and min.

So if you connect via 28.8 slip to a reflector that has 20
participants hooked up (like the Cornell Zoo reflector often does), you
could get 10-15Kbps of just conf control messages. (!) Even if you have NO
windows open. While it is useful for us to have such a loaded reflector to
provide a stress test, it probably doesn't make any sense to hook up to it
with a modem line unless at a very slack time of day.

If there are participants hooked to the reflector with caps set at
80, and lots of receivers (all those lurkers) have good connectivity and
report low loss, then one person hooking via modem will get one of those
80k streams by opening any window, along with the control message 15k.
Clearly this load will have to lose 60% or more in the terminal server.
Unfortunately the loss reports going back to the sender won't have much
impact amongst all the low-loss reports. With older versions when
automatically opening 8 windows and requesting video was the default (and
only) option, you can imagine the 600Kbit stream thundering down on the
poor terminal server, filing all its buffers, etc.

What to do? We should have out within a month some new reflector
code: it will look at the reported loss rates receivers are reporting and
then pre-emptively drop the packets right there at the reflector (why send
the if the net is just going to lose them?). This alone should help a lot.
Then we plan to implement an ability for a sender to generate a periodic
(every 15 sec, say) postage stamp size image. So if you don't have even
enough bw to receive one window, you can at least keep track of who is in
his chair. The reflector will also know enough not to even try to send 32K
audio to someone with a 28.8 pipe. On the other hand, it can give high
priority to 16k audio and drop only video (and control) packets.
Eventually we will have a proper layering scheme so that the streams sent
to each recipient can be just what it can use. A challenge will be to
provide a convenient user interface that allows someone to dynamically
express his preference for how scarce bw should be used.

So help is one the way, but for now, I think you just have to stay
away from really busy reflectors used by folks with higher bw connectivity.