W3C home > Mailing lists > Public > public-webrtc@w3.org > July 2013

Re: setting bandwidth

From: cowwoc <cowwoc@bbs.darktech.org>
Date: Thu, 25 Jul 2013 09:05:52 -0400
Message-ID: <51F122B0.3050403@bbs.darktech.org>
To: public-webrtc@w3.org

     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 
> <mailto: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
>     <mailto:goran.ap.eriksson@ericsson.com>> wrote:
>
>     >
>     >
>     > 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
>     >>
>
>
Received on Thursday, 25 July 2013 13:06:43 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:35 UTC