Re: Communcations Engineering and CUSEEME.
Fri, 1 Dec 1995 15:10:36 -0500

At 11:14 AM 11/30/95 -0500, Wilbur Streett wrote:
>At 10:35 AM 11/30/95 +0100, Ian Carr-de Avelon <> wrote:
>>One of the big problems there is that the phone lines are poor, 28.8kb modems
>>usually won't work.
>Won't work at all? V.42 modems are supposed to establish a connection at

[much good information about modems deleted]

>>In that case people using CU-See-Me through such a connection will appear to
>>have (extra) lost packets. If CU-See-Me responds by backing off, the rate of
>>the (extra) lost packets will remain the same, so it backs off further etc.

That's basically correct, Ian, that if there is a fixed loss ratio
independent of data rate, then the CU-SeeMe rate adaptation will just keep
slowing down. There is a parameter which sets the acceptable loss rate.
Reflector operators can configure this parameter for outgoing data streams,
but there is currently no access to it on the applications. I believe the
default is 3%, meaning that if you have consistent loss rates greater than
3%, the rate would continue to drop until it hit the user set floor.
As Wilbur says, though, the modem should adapt to the quality of the
line, so you wouldn't expect a constant loss ratio to persist if CU-SeeMe
were to slow down enough. I.e., the packet loss is probably buffer
overflow waiting for the modem, and it could be ameliorated with a better
tuned rate adaptation algorithm in CU-SeeMe.

>work begins. In other words, some level of effort to identify all of the
>issues would affecting performance would need to be done, and as issues are
>identified, the level of effort to resolve them can be estimated. Some of
>those issues that can be resolved easily may solve the overall performance
>issues that you are mentioning, or it may be that the design issues that are
>affecting the overall performance are "state of the art" issues that will
>take more raw research back in the labs and take years to resolve. Given
>the CUSEEME performance instability issues, I can imagine that some level of
>redesign is necessary. I would even go so far as to say that it's a lack of
>understanding of these communcations design issues that gave the original
>author the courage to develop CUSEEME where other more experienced
>communcation engineers would fear to tread. (metaphor intended..)

Well, there might be a bit of truth to the last statement. But, it was
more that we really didn't have much to be afraid of. Rather than us
deciding what kind of communication service people required, and then
trying to hit that spec, our design spec was basically to do what was
doable today, and then see if it would be useful. I.e., we let the quality
float to satisfy a fixed (minimal) effort investment, rather than letting
the effort float to achieve a predetermined result. So, you see, sitting
around for a couple of years and scratching our heads about all of the
issues affecting performance was never in the program (and I don't suppose
we could have afforded your consulting rates if it was). CU-SeeMe is
suboptimal in every dimension, and I'm proud of it.

>But I'm not going to solve White Pines and Cornells Data Communcation issues
>on anything less than my standard consulting rates. Like I said, this is
>where I make my living.
>So your ideas make sense in that you are starting to visualize what is going
>on with the sofware, but I don't believe that the modems are to blame. The
>design of CUSEEME should have been to work with "state of the practice"
>technology anyway.

Um, I think it was. What we were thinking about when we designed CU-SeeMe
in the summer of 1992 were basically university campuses, e.g., with mostly
Ethernets and T1 or better connections among them. We weren't sure how
well it would work, but figured it would probably be good for something,
and would only improve in utility as cpu's got faster and bandwidth became
more plentiful. I don't think we contemplated the idea that people would
be dialing in to the Internet, let alone that anyone would expect to do
videoconferencing that way. Now, if some folks find that CU-SeeMe
technology has some value in that context, I am thrilled, and hope we can
improve it. I think it's a fine tribute to modem engineering as well as
the robustness of our original design.


Tim Dorcey
CIT Network Resources (607) 255-5715
Cornell University
Ithaca, NY 14853