Re: Restrictions on transimssion rates if isdn used with cuseeeme?

Mark Badger (mark@steinberg.net)
Mon, 10 Feb 1997 20:37:20 -0800


Brian O'Shea wrote:
>
> -i wrote:
> -so: if a reflector is set up to accept a client rec cap of 30, and a
> -client connects with a rec cap of 200, the stream the client gets sent
> -is as if the client had connected at 30 ? hey presto ?
>
> Agreed, it's a piece of cake.
>

excellent. so we are half the way there. no ?

> -i can see that the problem is perhaps trickier with the send cap, but
> -the same principal may well apply equally as effectively ?
>
> Exactly. This is necessary to restrict what a client is sending to the
> reflector. If the reflector couldn't control that, it would be lacking a
> large amount of functionality.
>

indeed. yet the reflector could take a two-stage strategy in dealing
with the problem (??):

stage 1: the reflector only accepts a given flow rate, discarding a
random
distribution of the extra packets. (i admit that it is purely
speculation
on my part that this strategy would work, i presume it would have an
effect
much like that produced by connecting through some busy routers). the
problem would be, i presume, that the reflector's host would still be
receiving an
input stream which exceeds the bandwdith estimation established by the
administrator. the host processing would be minimized at least. i have
not
looked at the client sources so i am not aware of what happens when it
records that a given number of packets it sends to a ref are being lost.
perhaps it can be "fooled" into sending fewer packets ? negative packets
being lost ?

stage 2: the reflector negotiates a new flow rate with the client just
as
you propose. if you people at white pine were willing to publish the
format
and negotiation sequence of that process then those of us who seek to
improve the freeware client could make the cornell version compatible.

i've no idea what your licensing agreement is, but i have studied the
agreements
for people like me and i can see that i must contribute any changes i
happen
to make back to you and cornell. it would seem only fair for wpine to at
least
publish the necessary header files and sequence?

> -what seems to be a problem with the strategy, as outlined, is that White
> -Pine are effectively improving the behaviour of their reflector/client
> -relationship without solving the issue at hand in a manner that is
> -compatible with any client.
>
> How would you solve the send cap problem on older clients?

see above. what are the reasons for limiting the cap anyways ? is it a
pipe
thing ? in which case the streams will be compteting for bandwidth
anyways,
or is it a host-processing overhead thing, in which case the discarded
packet scheme will offer a degree of relief.

> We will have to send the message that tells them that they
> have to change their send cap, and that's all there is to it. If we don't
> they will send at rates greater then the reflector administrator wants them
> to, and that's simply unacceptable.

understood.

> All that you can reasonably expect us to do is to maintain compatibility with
> existing clients and reflectors while we make improvements to the newer ones.

i think we might expect you (wpine) to "publish" the format and sequence
of
the rate negotiation sequence that you implement.

<SNIP>

> So, we're fixing it, like it should have been in the first place, and
> moving onto the next thing.
>

for which we are all grateful ! bravo !

m