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

Re: setting bandwidth

From: Kiran Kumar <g.kiranreddy4u@gmail.com>
Date: Wed, 24 Jul 2013 20:35:05 +0530
Message-ID: <CAGW1TF6c--Mge_LBum9Jptx6dAh-5Q_+ub+uA8HraemB1TbHzA@mail.gmail.com>
To: "piranna@gmail.com" <piranna@gmail.com>
Cc: Göran Eriksson AP <goran.ap.eriksson@ericsson.com>, cowwoc <cowwoc@bbs.darktech.org>, "public-webrtc@w3.org" <public-webrtc@w3.org>
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.


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 15:05:55 UTC

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