Re: setting bandwidth

Hi Martin,

     I feel that callback API with timers is a good solution instead of
application continuously polling and calling the stats API for identifying
the bandwidth usage. The callbacks will work only if the upper and lower
bounds are set. (I agree with Gili, for the use cases specified, to set
this value). If the application don't want to know about the bandwidth and
rate controlling, it can avoid callbacks by continuing with default values,
which can be zero for min fence and a very big value for max fence. Timers
will only control the number of callbacks when they are supposed to invoke
(as I specified earlier to avoid callback congestion inside the
application). The timers also will have default values (which will be
discussed and decided later). If the application wants to set its specified
values for timers, then we can`t set them with b= lines of SDP. There
should be some provision to set these, so I thought we can use constraints
for this purpose.

Thanks,
Kiran.



On Sat, Jul 27, 2013 at 10:10 PM, cowwoc <cowwoc@bbs.darktech.org> wrote:

>  On 27/07/2013 11:58 AM, Martin Thomson wrote:
>
> On 25 July 2013 21:24, Kiran Kumar <g.kiranreddy4u@gmail.com> <g.kiranreddy4u@gmail.com> wrote:
>
>  The timer implementation I suggested, is to avoid the error condition that
> can arise as a result of Gili's proposal callback API.
>
>  Unfortunately, having a specific timer-based constraint will cause
> problems.  Different browsers are likely to implement very different
> rate control mechanisms, as we have already seen with the video
> comparison tests (in RTCWEB).  The time periods over which bandwidth
> is controlled and how rate control is implemented are intimately tied.
>  What this sort of mechanism is likely to do is force applications to
> learn about the intricate detail of each browser (probably using user
> agent sniffing techniques) in order to control the bandwidth consumed.
>
> In some respects, Cullen's proposal is elegant, but I think that we
> really need a mechanism that effectively just sets the b= line in SDP.
>  Note that this doesn't necessary have to be negotiated as long as the
> number that is set is lower than the negotiated value.  However, for
> consistency purposes, I'd probably just make this a constraint on
> createOffer and maybe createAnswer, which would force the use of
> setLocalDescription etc...
>
> Also, to anyone considering a minimum value for a bandwidth
> constraint.  There is no way that this would ever be a good idea.  The
> browser will have to respect the congestion signals it receives and
> reduce bandwidth accordingly.  Allowing an application to force a
> minimum rate would allow bad actors to generate congestion on the
> Internet.  Besides, good codecs encode still images and silence at
> near zero rates during normal operation, we wouldn't want to prevent
> that.  Minimum target quality levels are something else, of course.
>
>
> Martin,
>
> This is precisely why I believe users should be able to specify "fences"
> and callbacks. There are a lot of cases where the application knows better
> than the browser what should happen when a fence is crossed.
>
> Here is my use-case for minimum bandwidth:
>
>    - I'm running an application that requires 1080p video. A lower video
>    resolution is unacceptable. It is my job to guarantee the existence of a
>    3MBit synchronous pipe. If, for whatever reason something goes wrong, I
>    expect to be able to handle the failure condition (i.e. the application
>    should decide, not the browser).
>     - Each fence condition (congestion, mute, etc) would get handled
>    differently by the application. In the case of congestion, I might kill the
>    video feed altogether or display an error message and terminate the call.
>    In the case of mute, the application could avoid a fence condition by
>    enabling video mute and changing the minimum bandwidth to zero at the same
>    time. When un-muting, it would restore the minimum bandwidth fence.
>     - Practically speaking: the current behavior (assuming minimum
>    bandwidth is zero) results in very poor video quality during the first
>    minute the video session begins. Applications that use 1080p need to wait a
>    minute for the session to "warm up" before they can conduct any meaningful
>    dialog. Even if this time were reduced to 10 seconds it would be
>    unacceptable. I expect an immediate sharp video experience.
>
> Gili
>