Re: setting bandwidth

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 02:12:51 UTC