Re: Refs or no refs

Brian Godette (bgodette@idcomm.com)
Mon, 27 Oct 1997 12:53:48 -0700


At 09:34 AM 10/26/97 +0100, you wrote:
>Jason Williams wrote:
>> The reason it's a good thing is because it allows you see and be seen
>> by multiple people. This is compared to software like Freevue and
>> iVisit which allow multipoint conference without a reflector but the
>> bandwidth you send at is reduced for each person that wishes to see
>> your vid. If you are sending 20kbps and you have 5 people watching
>> you, each person only gets an average of 4kbps from you. With
>> CU-SeeMe, if you send 20kbps on a reflector, everyone can get you at
>> 20kbps regardless of how many people are watching you.
>If You don=B4t have at least a T1 connection (no private Internet client
>has such in Europe !), that=B4s the baddest thing with CU (I am connected
>by 28.8 kbps / 33.6 kbps):
>
>If You would like to see just a few people, selectively (because You
>know that Your bandwidth is limited), everything works fine with iVisit,
>if not too many people want to watch the same person.
>
>On an occupied, busy CU-ref, You don=B4t see a single picture of a / any
>user even after 10 minutes, or so.=20
>
>Especially lets discuss about the negative influence of "lurkers"
>(people without cams) on the bandwidth available for "true" users with
>cam ! From my point of view, they are bad anyhow, but with Cu refs, they
>ruine the system performance overall. It is really the bad thing for CU
>refs that lurkers ***receive*** video ?!!! Think about it !!

Ummmm, I have, and that's not how refs work :) It's all a matter of simple
math (with some assumed averages for "idle" clients). Ok here goes.....

Roughly 200-300 bytes (depending on client used) for OC packets is
received from each client connected to a specific conference over a period
of 10 seconds, each client has an interval of 10 seconds. This works out to
a sustained rate of roughly 1.5kbps per every two *other* clients on a WP
or EREF reflector.
For a Cornell ref it's much worse, add 12 bytes per client after the
first one on top of the 200-300 bytes, (N-1)*12, with the same interval. So
for a "full" ref of about 20 clients you'll have a sustained rate of
roughly 3kbps per client.

Depending on how much chat is moving around, recovery status packets of
26+(16*N) bytes, N being the number of chat lines sent by a client in the
last 60 seconds, are sent every 5 seconds from any client that has sent
chat in the last 60 seconds.
Chat packets themselves are 58+LengthOfNick+LengthOfMessage, and are
sent three times inititally, all recovered lines are sent as
client-to-client messages and do not impact other clients.

(This is starting to look like astronomical equation eh? <grin>)
So, for an idle client (sender or lurker, there is *no* difference), that
you don't have the vid open for and isn't saying anything in chat, thier
impact on your receive rate is all of 200-300 (highly compressable mind
you) bytes at an interval of 10 seconds. Essentially nothing. If that same
client is chatting, the impact is a bit more, that same 200-300 bytes plus
another 300 or so in one burst (initial chat packet) and say around 90
bytes every 5 seconds. Over a 10 second interval that's about 680-700 bytes
of compressable data. Now take into account that in 10 seconds with a 28.8
connect you can receive roughly 35Kbytes of data you begin to see that this
isn't such a big deal (roughly 2% of your total bandwidth per client). Now
if you're really paying attention, you'll notice that 38% of your bandwidth
is consumed when a conference reaches 20 clients (you're receiving
information from N-1 clients), which is why the 15Kbps max transmission
rate starts to make sense, it gives you about a 9% buffer zone for a
conference that size.