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

Brian Godette (bgodette@idcomm.com)
Tue, 11 Feb 1997 14:56:49 -0700


On Mon, 10 Feb 1997 14:24:00 -0800
Mark Badger <mark@steinberg.net> wrote:

> Brian O'Shea wrote:
>
> > -This is a very simple concept, and should be easy to implement, tho it
> would
> > -require changes to both the reflector and the client. The new reflector
> > -code would check the version of the client, and if it's new enough and has
> > -the capability, then the adjustment messages would be sent. If the client
> > -is too old, then you would just get the same old "Please adjust..."
> message.
> >
> > We're making sure the upcoming 3.0 client has this functionality so that
> when
> > the 3.0 reflector comes out later on, the 3.0 clients will automatically
> > adjust to the reflectors settings.
> >
>
> why perform these adjustments at the client end ? as you say yourself,
> this leads to a versioning problem. much better to do it in the
> reflector, then it is controlled "at source" and it will be compatible
> with any client ?
>
> 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 ?

Easy enough to implement. In fact the data stream the client receives is
limited to the client's max receive setting. If the reflector were to
simply "adjust" the max setting down to the max-max-receive/conf-max-max
-receive setting... presto!
>
> i can see that the problem is perhaps trickier with the send cap, but
> the same principal may well apply equally as effectively ?

A similar method could be used for send caps. The current clients, both
Cornell and White Pine, support dynamic rate adaption. If the reflector
reported "fictitiously high" loss reports for the data the client is
sending to the reflector, the client will automagically lower it's max
send rate. The trick is to keep "lost" packet count balanced such that
the client's max send stays under the reflector's max setting. This is a
bit of work, but would produce the desired result without breaking any of
the current clients.

>
> 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.
>
> m