Re: Newsgroups.

Tim_Dorcey@cornell.edu
Thu, 13 Oct 1994 22:08:07 -0400


>I like, and I'll add this. What I haven't gotten is a peep from CU.
>Hello? Did everyone take the week off?

There seem to be a number of issues here. For the basic question of
newsgroup versus list, I don't have a strong opinion--I'm going to read it
all anyway. If newsgroups are going to be created, however, I would object
to putting them under "multimedia," which makes me think of authoring
rather than communicating (plus, I personally hate the term
multimedia...aren't we really just talking about 2 media: audio and
video?). It seems like comp.dcom would be the natural place in the
hierarchy. The second question is whether putting it in the newsgroup
hierarchy is going to greatly expand its use. I don't know. I do have an
opinion on whether I'd like to see CU-SeeMe use expand in the immediate
future: basically, wherever there is unused network capacity, I'd like to
see it filled with CU-SeeMe packets, and wherever CU-SeeMe is disrupting
lower bit-rate traffic, I'd like to see its use decrease. How's that?
Anybody care to quarrel?
In all seriousness, with a little more work, I believe we can come
fairly close to achieving that objective. As I have mentioned in previous
posts, the big problem with CU-SeeMe's current network behavior is that the
only way receivers can control the volume of data coming there way is to
open and close windows. What we need is a way to send each conference
participant only as much data as their connection is able to support. A
hierarchial video encoding scheme is in the works that will allow
reflectors to forward different amounts of data to different recipients
with a predictable effect on video quality. But, as an interim measure, we
soon intend to add code to the reflector that will cause it to simply drop
random packets to achieve the target rate per recipient--clearly the
layered encoding scheme is better, but in the meantime, if we know the net
is going to drop the packets anyway, we may as well have the reflector do
it. The remaining trick is to determine the proper target rate. Video
senders currently run a cut back, creep up algorithm to adjust there
transmission rate based on packet loss reports, in search of the proper
target. This seems to work fine for a fixed capacity link, and could
easily be adapted to find a per-recipient rate on the reflector. The
problem, of course, is that in most cases the capacity is not fixed, but
depends on how much competing traffic there is, which varies as the
competing traffic also cuts back and creeps up. I don't know how the
CU-SeeMe rate control algorithm coexists with a bunch of TCP connections,
but it shouldn't be that hard to come up with a reasonable approach. [Hey,
anybody have time to help us out with some quick experiments? Try running
CU-SeeMe point-to-point along with some big ftp's over some low capacity
link and measure the throughputs. Does CU-SeeMe's rate cap stabilize? How
does it compare to the ftp throughput?]. Incidentally, one of our
thoughts, half in jest, but maybe worth looking further at would be for
CU-SeeMe to open a TCP stream, run it for a while, see what kind of
throughput it gets, and then set CU-SeeMe's rate cap to that value. It
would be fair in the sense that you would expect to get about as much
bandwidth as someone doing an ftp would.
If we do this work properly, than what many people may find is that
CU-SeeMe is not useful across certain links during certain times of the
day. Or, perhaps they can only get decent frame rates if they close all
but 1 window, or shrink them to smaller (not yet available) sizes. Please
don't get the idea that I think that this provides a simple technological
escape from the policy issues that have been raised in this discussion.
There will still be lots of room for argument about how networks should be
used. I am hoping, however, that we can improve CU-SeeMe to the extent
that these arguments can be conducted in a leisurely, civilized manner,
with as few emergencies as possible, and that the software contains the
flexibility to allow implementation of whatever policy decisions are made.

-Tim
__________________________________________________________________
Tim Dorcey T.Dorcey@cornell.edu
Sr. Programmer/Analyst (607) 255-5715
Advanced Technologies & Planning
CIT Network Resources
Cornell University
Ithaca, NY 14850
__________________________________________________________________