Re: setting bandwidth

As it turns out there are three possibilities as Cullan brought up the
stats API.

I'll need to think more deeply about the advantages/disadvantages of each
is all I meant.

Silvia.
On 26 Jul 2013 13:22, "cowwoc" <cowwoc@bbs.darktech.org> wrote:

> Silvia,
>
>     I was referring to http://lists.w3.org/Archives/**
> Public/public-webrtc/2013Jul/**0601.html<http://lists.w3.org/Archives/Public/public-webrtc/2013Jul/0601.html>where you wrote "Both are probably necessary actually." Didn't you mean to
> imply that we'll probably need timers on both levels? I thought you meant
> that we'll need a single generic threshold for the internal timer, and then
> a different user timer depending on what property was changed.
>
>     Anyway, my main interest here is the use of callbacks and fence
> conditions. The suggestion for a timer came from Kiran. We can start
> without it and add one as needed.
>
> Gili
>
> On 25/07/2013 10:12 PM, Silvia Pfeiffer wrote:
>
>> That's not what I said. I don't know what the efficiency implications
>> are and I just think it needs more analysis. Somebody needs to sit
>> down and at least on paper think through the implications of each of
>> these choices with some well-informed assumptions about what an
>> application would do. Which approach would require more interrupts?
>>
>> I don't have time right now, but maybe you can have a go?
>>
>> Cheers,
>> Silvia.
>>
>> On Thu, Jul 25, 2013 at 11:05 PM, cowwoc <cowwoc@bbs.darktech.org> wrote:
>>
>>>      Silvia is right: we need timeout handling inside the Constraints
>>> API or
>>> user callback.
>>>
>>> Gili
>>>
>>>
>>> On 24/07/2013 7:43 PM, Silvia Pfeiffer wrote:
>>>
>>> That instead requires the JS to constantly poll the stats objects for
>>> updated information. I'm not sure that's more efficient approach than a
>>> callback.
>>>
>>> Silvia.
>>>
>>> On 25 Jul 2013 08:00, "Cullen Jennings (fluffy)" <fluffy@cisco.com>
>>> wrote:
>>>
>>>>
>>>> Given the general focus on moving as much state as possible out of the
>>>> browser and into JS, it seems like it would be better to just do things
>>>> like
>>>> timers and level monitors and such in JS and just have them query the
>>>> stats
>>>> objects.
>>>>
>>>>
>>>> On Jul 24, 2013, at 9:23 AM, Göran Eriksson AP
>>>> <goran.ap.eriksson@ericsson.**com <goran.ap.eriksson@ericsson.com>>
>>>> wrote:
>>>>
>>>>
>>>>> 24 jul 2013 kl. 17:05 skrev "Kiran Kumar" <g.kiranreddy4u@gmail.com>:
>>>>>
>>>>>  Dear Piranna,
>>>>>>
>>>>>> If the network state is not stable, and if the bandwidth levels are
>>>>>> oscillating at the border. (like at around 1Mbit as stated in previous
>>>>>> example). There is a chance for raising more number of call backs
>>>>>> with in
>>>>>> less time and may result in call-back congestion
>>>>>> (http://forums.electricimp.**com/discussion/176/possible-**
>>>>>> callback-congestion-causes-**hang/p1<http://forums.electricimp.com/discussion/176/possible-callback-congestion-causes-hang/p1>
>>>>>> ).
>>>>>> Maintaining some window timer at lower levels will reduce this
>>>>>> problem.
>>>>>>
>>>>>> According to Congestion Manager RFC (RFC 3124),
>>>>>> Callback-based transmission, and other call back based implementations
>>>>>> like TCP congestion control algorithms are all implementing timers at
>>>>>> the
>>>>>> lower layers
>>>>>>   only.
>>>>>>
>>>>>>
>>>>>>  Good point. I had in mind waiting with pushing the timer to the
>>>>> browser
>>>>> until we have more experience on real use cases but this was a
>>>>> compelling
>>>>> argument for doing it already know.
>>>>>
>>>>> Thanx
>>>>>
>>>>>
>>>>>  Thanks,
>>>>>> Kiran.
>>>>>>
>>>>>>
>>>>>> On Wed, Jul 24, 2013 at 7:05 PM, piranna@gmail.com <piranna@gmail.com
>>>>>> >
>>>>>> wrote:
>>>>>> It's not bad to have the timers inside the API, but I would wait until
>>>>>> more clear use cases apear.
>>>>>>
>>>>>> 2013/7/24 Kiran Kumar <g.kiranreddy4u@gmail.com>:
>>>>>>
>>>>>>> Dear Goran Eriksson/Piranna,
>>>>>>>
>>>>>>> Yes, It can be done by application too.
>>>>>>> But maintaining such timer in the lower level, might be more
>>>>>>> appropriate. It
>>>>>>> will reduce unnecessary call backs.
>>>>>>> (Even though this is may not be the perfect example, some signaling
>>>>>>> protocols like SIP are maintaining their timers in the lower layers
>>>>>>> instead
>>>>>>> of application layer).
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Kiran.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Jul 24, 2013 at 6:47 PM, Göran Eriksson AP
>>>>>>> <goran.ap.eriksson@ericsson.**com <goran.ap.eriksson@ericsson.com>>
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 24 jul 2013 kl. 15:04 skrev "Kiran Kumar"
>>>>>>>> <g.kiranreddy4u@gmail.com>:
>>>>>>>>
>>>>>>>> This seems to be nice Idea to send callbacks.
>>>>>>>> But I suggest to add some timer on top of it. Like If the bandwidth
>>>>>>>> drops
>>>>>>>> below a certain minimum level, then it should wait for a predefined
>>>>>>>> window
>>>>>>>> time, if the bandwidth is still less than the minimum limit, then
>>>>>>>> only it
>>>>>>>> should send a call back.
>>>>>>>> Because there are many network scenarios, that affects the bandwidth
>>>>>>>> for a
>>>>>>>> minute period of time, and recover to its normal state soon.
>>>>>>>>
>>>>>>>>
>>>>>>>> That is an option but is that not up to the application to have a
>>>>>>>> timer, a
>>>>>>>> counter or what ever is needed to decide on an action?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Kiran.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Jul 24, 2013 at 11:16 AM, cowwoc <cowwoc@bbs.darktech.org>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> On 24/07/2013 12:26 AM, Cullen Jennings (fluffy) wrote:
>>>>>>>>>
>>>>>>>>>> On Jul 18, 2013, at 6:21 AM, Stefan Håkansson LK
>>>>>>>>>> <stefan.lk.hakansson@ericsson.**com<stefan.lk.hakansson@ericsson.com>>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>  2. Setting BW for a MediaStreamTrack
>>>>>>>>>>> ------------------------------**------
>>>>>>>>>>> Why: There are situations where a suitable start bit-rate can be
>>>>>>>>>>> known,
>>>>>>>>>>> or guessed. If this knowledge could be used the perceived
>>>>>>>>>>> end-user
>>>>>>>>>>> quality could be improved (since a higher quality is available
>>>>>>>>>>> from
>>>>>>>>>>> start since there is no need to start at a really low bit-rate).
>>>>>>>>>>>
>>>>>>>>>>> There are also situations where it could be beneficial if min and
>>>>>>>>>>> max
>>>>>>>>>>> bit-rates to be used can be influenced.
>>>>>>>>>>>
>>>>>>>>>>> * The app developer may know that below a certain bit-rate the
>>>>>>>>>>> quality
>>>>>>>>>>> is so bad that the browser could stop sending it, and likewise
>>>>>>>>>>> there
>>>>>>>>>>> may
>>>>>>>>>>> be knowledge about a bit-rate above which the quality does not
>>>>>>>>>>> improve.
>>>>>>>>>>>
>>>>>>>>>>> * There are situations when there is an agreement between the
>>>>>>>>>>> service
>>>>>>>>>>> provider and the connectivity provider about min and max
>>>>>>>>>>> bit-rates.
>>>>>>>>>>>
>>>>>>>>>>> What: Again, this depends on how much BW info is included in the
>>>>>>>>>>> SDP.
>>>>>>>>>>> But my understanding is that there should be some (since RTCP
>>>>>>>>>>> rates to
>>>>>>>>>>> be used are based on this info IIUC).
>>>>>>>>>>>
>>>>>>>>>> I agree and think we need to a couple things here. One is setting
>>>>>>>>>> the
>>>>>>>>>> limits for the bandwidth but the  other is using the stats
>>>>>>>>>> interface to read
>>>>>>>>>> the current bandwidth being used.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>      A slightly related but higher-level proposal: replace
>>>>>>>>> Mandatory
>>>>>>>>> constraints with Optional constraints that act as Fence conditions.
>>>>>>>>>
>>>>>>>>>      It works like this: You specify a bunch of optional
>>>>>>>>> constraints
>>>>>>>>> and a
>>>>>>>>> callback to be invoked when a Constraint is violated. For example,
>>>>>>>>> I would
>>>>>>>>> ask for a bandwidth between 1Mbit and 2Mbit. If bandwidth drops
>>>>>>>>> below the
>>>>>>>>> minimum, the callback gets invoked. I then reduce the video
>>>>>>>>> resolution, or
>>>>>>>>> turn off audio, or... whatever the application wants... and set new
>>>>>>>>> min/max
>>>>>>>>> bandwidth bounds. If the maximum bound is surpassed, I know I can
>>>>>>>>> afford to
>>>>>>>>> increase the video resolution so I do so. And so on.
>>>>>>>>>
>>>>>>>>>      Assuming I'm wrong (you need mandatory constraints) I still
>>>>>>>>> think
>>>>>>>>> adding this fence behavior puts control in the right place. The
>>>>>>>>> application
>>>>>>>>> is uniquely positioned to decide what happens when the connection
>>>>>>>>> capabilities change.
>>>>>>>>>
>>>>>>>>> Gili
>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>>> --
>>>>>> "Si quieres viajar alrededor del mundo y ser invitado a hablar en un
>>>>>> monton de sitios diferentes, simplemente escribe un sistema operativo
>>>>>> Unix."
>>>>>> – Linus Tordvals, creador del sistema operativo Linux
>>>>>>
>>>>>>
>>>>
>