Re: setting bandwidth

Both are probably necessary actually.
Silvia.
 On 25 Jul 2013 01:07, "Kiran Kumar" <g.kiranreddy4u@gmail.com> wrote:

> 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
>>
>
>