This was one of my motivations to develop TFWC (a window-based CC, but
still useful for the real-time video streaming applications) -
On 1/26/11 2:21 AM, Saverio Mascolo wrote:
> to complete my previous msg, here it is a paper
>
>
http://c3lab.poliba.it/images/8/88/ACM04.pdf
>
> that describes "a rate based control" that is the**_*real *_rate-based
> counterpart of TCP window based control.
>
> It is real because it is a dynamic equation and not a steady state
> equation as TFRC. As a consequence, it responds in real-time respond to
> network conditions, as it does TCP, but in real-time.
>
> As any algorithm that computes a rate, it should be implemented using a
> "rate mismatch controller"
>
>
http://c3lab.poliba.it/images/d/d9/Icnp09.pdf
>
> Any comment is very welcome!
>
> Thanks for the attention and best regards,
>
> saverio
>
>
> On Tue, Jan 25, 2011 at 4:49 PM, Rosenberg, Jonathan
> <
jonathan.rosenberg@skype.net <mailto:
jonathan.rosenberg@skype.net>> wrote:
>
> No debate here. The model I like is that there is something built-in
> to the browser (say, TFRC or some variant), but the hooks are
> available to allow an application to customize it.
>
>
>
> -Jonathan R.
>
>
>
> Jonathan D. Rosenberg, Ph.D. SkypeID: jdrosen
>
> Chief Technology Strategist Mobile: +1 (732) 766-2496
>
> Skype SkypeIn: +1 (408) 465-0361
>
> <mailto:jdrosen@jdrosen.net>
> tom_harper@logitech.com <mailto:tom_harper@logitech.com>; 'Justin
> <mailto:rtc-web@alvestrand.no>; 'Peter Musgrave'
>
> *Subject:* Re: [RTW] Rate control and codec adaption (Re: [dispatch]
> The charter formerly know as RTC-WEB take 3)
>
>
>
> Agreed, but for the purpose of this discussion I believe that rate
> control of some sort should also be a MUST.
>
>
>
> Web browsers are extremely prevalent, and we hope that RTC use in
> browsers will be high, and so it would be good for the Internet for
> browsers to have sending rate control. Note that this is at the
> protocol level... so send rate must be controlled whether the codec
> can have its rate adjusted downward so as to not require the
> protocol level to enforce or not.
>
> For interoperability, it is also required that the feedback
> mechanism from one end to the other be standardized, even if the way
> that feedback is used to control send rate and/or codec selection or
> codec rate selection is proprietary and/or extensions to the
> feedback are also sent for endpoints that understand the (possibly
> proprietary) extension(s).
>
> Matthew Kaufman
>
> On 1/25/2011 7:38 AM, Rosenberg, Jonathan wrote:
>
> It’s a proprietary algorithm of our own design, supported by some
> protocols which exchange feedback in real-time between endpoints.
> We’re constantly tweaking it based on user feedback and technical
> statistics we collect.
>
>
>
> Indeed – as many folks are aware, rate adaptation has always been an
> area of innovation and differentiation. RTP has provided the tools
> for feedback but has allowed implementations to do whatever they
> want. I think it is important that this continues to be the case in
> the web world – that folks designing RTC applications can innovate
> and define their own versions of these algorithms.
>
>
>
> Thanks,
>
> Jonathan R.
>
>
>
> Jonathan D. Rosenberg, Ph.D. SkypeID: jdrosen
>
> Chief Technology Strategist Mobile: +1 (732) 766-2496
>
> Skype SkypeIn: +1 (408) 465-0361
>
> <mailto:jdrosen@jdrosen.net>
>
http://www.jdrosen.net
>
>
>
>
>
>
>
>
> --
> Prof. Saverio Mascolo
> Dipartimento di Elettrotecnica ed Elettronica
> Politecnico di Bari
> Via Orabona 4, 70125 Bari Italy
> Tel. +39 080 5963621
> Fax. +39 080 5963410
>
>
http://c3lab.poliba.it
>
>
> =================================
> This message may contain confidential and/or legally privileged
> information.
> If you are not the intended recipient of the message, please destroy it.
> Any unauthorized dissemination, distribution, or copying of the material in
> this message, and any attachments to the message, is strictly forbidden.
>
>
>