Re: Reflector Questions

Jason Williams (
Tue, 14 Apr 1998 11:00:56 -0500 (CDT)

On Tue, 14 Apr 1998, Digisite wrote:
> I feel kinda stupid but have some really basic and hence really dumb questions
> with regard to reflectors that I'm sure one of you gurus can easily
> answer..............

I can give it a shot...though I don't consider myself a guru really :)

> (1) is a T1 connection 1.5 million "bits" or 1.5 million "bytes" per second

It's bits.. modems are 28.8 kilobits/sec.. T1 is 1.5 Megabits/sec

>From what I've seen, when you're talking about transmission of data, it's
generally in bits..when you're talking about storing data on a disk
somewhere, it's in bytes. So the bandwidth of a modem is typically 28-56
kilobits/sec...While a typical hard drive these days is severak gigabytes.

What I've heard in the to roughly divide the kilobits/sec by 10
to get kilobytes/sec. (8 bits, no parity, one stop bit or something like

> In trying to calculate reflector bandwidth usage.....hypothetically.
> Assume a reflector conference with 9 users, each user has a 28.8 connection
> (is the 28.8 full duplex?).

Yeah, it's full duplex with the ability to send 28kbps and receive 28kbps.

> The reflector is configured for a max send rate of
> 20, a max rec rate of 20, all 9 users have 8 other windows open, and there is
> no packet loss for any of the paths (hypothetically of course !).
> (2) would the bandwidth be calculated as 180kbs incoming TO the reflector and
> the bandwidth OUT of the reflector to the network be 1.28 mega"bits" or 1.28
> mega"bytes" per second or some other value?.

Let's see what I come up with...assuming no packet loss and also ignoring
the overhead of the OT packets being send to each user (with only 9 users,
it should only be 2-3kbps per participant):

The key factor I see is that you (as a reflector operator presumably) have
limited the max send and max receive rates. So, with a max send of 20 and
a max receive of 20, each participant can receive no more than 20kbps
irregardless of how many windows he/she has open. They can also send no
more than 20kbps.
For outgoing bandwidth from the reflector: 9 X 20kbps = 180kbps total
For incoming bandwidth to the reflector: 9 X 20kbps = 180kbps total

So the total bandwidth is 360kbps split evenly between sending and

Without the limitations on the receiving kbps, someone on a T1 could pop
on with a max receive of 500kbps (the reflector default) and then receive
8 X 20kbps = 160kbps for just one participant. If you have a few people
do that, it can easily suck down a T1. (Modem users only dent the
bandwidth if there's enough of or two T1 users can wipe out the

Back when there used to be more higher bandwidth users on CU-SeeMe, I
often remember sending 150kbps and watching 5-6 other participants and
receiving 600kbps total. Needless to say, the reflectors were on T3s so
bandwidth wasn't a concern at the time :)

> (3) is there a completely seperate data stream sent from the reflector for
> each sender to each user or is there only one data stream sent from the
> reflector for each sender and the clients just pick them out?

Good question...The reflector uses unicasting to accept and send out
streams, but that only means it sends out one stream per client. That's
one reason reflectors don't scale very well (multicasting may help that
depending on the multicast routing protocol used).

So the answer is no, it doesn't send out a seperate "stream" from each
client if you mean a seperate connection. From what I understand of the
CU-SeeMe protocol (which could be completely off), the multiple vids are
multiplexed into one stream and sent to the client. There's only one
connection open and the packets are streamed thru (with each packet being
a known length or a length that can be determined from the header)...Brian
Godette probably knows a lot more about this though.

You'd have to understand a bit of networking I'd imagine..It's not so much
that the client "picks it out" as it is receiving UDP packets that it
decodes to be video streams.

> (4) does this bandwidth usage depend on each users movement and if everyone is
> holding fairly still, the bandwidth would be considerably less?

For the grayscale, yes. For the color codecs, I don't believe so.
The Cornell grayscale codec uses frame differencing...when the frames
don't differ (ie: little movement), then not much is sent. I've had fun
with this by trying to sit perfectly still and watching my sending kbps
drop to 3-4kbps or so and my frame rate jump up to 6-7fps. You can also
simulate fast motion this way. Stand still then move your finger (and
only your finger) and it will appear to be moving quite fluidly.

As for the color codecs, I know MJPEG sends complete frames. The
bandwidth used is determined by the quality settings (which determines the
size of each frame I believe).

> (5) can NV be used to link conferences of the same reflector or can it only be
> used to link different reflectors (is there another way besides NV) ?

NV can't be used to link anything as far as I know...NV is mainly used to
allow the NV unix client to connect to the reflector. It doesn't handle
linking conferences. For that, try the BCC options to send and receive
streams to/from another reflector. One of my suggestions to White Pine
was to allow the ability to link conferences within the same reflector,
but found out it would be a rather large undertaking. The only other way
to simulate linked conferences is to use the Root ID.

Hope that helps...

<back to Java>

--    * Jason Williams -- Austin, Tx.  |     |       * University of Texas at Austin  | ___ |         * BS Computer Science             \_|_/
*************** **************|