Re: setting bandwidth

24 jul 2013 kl. 17:05 skrev "Kiran Kumar" <g.kiranreddy4u@gmail.com<mailto: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<mailto:piranna@gmail.com> <piranna@gmail.com<mailto: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<mailto: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<mailto:goran.ap.eriksson@ericsson.com>> wrote:
>>
>>
>>
>> 24 jul 2013 kl. 15:04 skrev "Kiran Kumar" <g.kiranreddy4u@gmail.com<mailto: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<mailto: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<mailto: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