- From: Göran Eriksson AP <goran.ap.eriksson@ericsson.com>
- Date: Wed, 24 Jul 2013 22:25:29 +0000
- To: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
- CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
Yes I had thought along those lines myself but Kiran do bring up a valid point which I think motivate some more reflection and some more testing. GE 24 jul 2013 kl. 23:57 skrev "Cullen Jennings (fluffy)" <fluffy@cisco.com>: > > 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 Wednesday, 24 July 2013 22:25:54 UTC