Re: setting bandwidth

Silvia,

     I was referring to 
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> 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).
>>>>> 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> 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> 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
>>>>>
>>>

Received on Friday, 26 July 2013 03:22:33 UTC