Re: setting bandwidth

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