Re: setting bandwidth

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
>