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