Re: setting bandwidth

Hi,
The timer implementation I suggested, is to avoid the error condition that
can arise as a result of Gili's proposal callback API.
IMHO, instead of invoking the callback, a timer should be started. A have
to think more deeply on where and how to handle of the timer, and various
scenarios that we can expect while we are handling it (may be the bandwidth
may come to normal state by the time of handling, or it might have still be
degraded etc..).

For now, I am thinking of the initiation of timers like this.
There should be a default pre-defined value for timer (may different values
for different scenarios).
Provision for application developer to modify the timer value, only for the
allowed cases, through constraints API.
In other cases it should return and exception.

Thanks,
Kiran.



On Fri, Jul 26, 2013 at 8:54 AM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com>wrote:

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