[RTW] Rate control and codec adaption (Re: [dispatch] The charter formerly know as RTC-WEB take 3)

Soo-Hyun Choi soohyun.choi at cl.cam.ac.uk
Tue Jan 25 18:36:02 CET 2011


So, your first and second paper addressed issues around these problem,
respectively:

(1) limitations of the TCP equation used by TFRC
(2) limitations of being rate-based

This was one of my motivations to develop TFWC (a window-based CC, but
still useful for the real-time video streaming applications) -
http://tfwc.hackerslab.eu/.

Any comments?

Cheers,
Soo-Hyun



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 at skype.net <mailto:jonathan.rosenberg at 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
> 
>     jdrosen at skype.net <mailto:jdrosen at skype.net> 
>                             http://www.skype.com
> 
>     jdrosen at jdrosen.net
>     <mailto:jdrosen at jdrosen.net>                       
>     http://www.jdrosen.net
> 
>      
> 
>     *From:*Matthew Kaufman [mailto:matthew.kaufman at skype.net
>     <mailto:matthew.kaufman at skype.net>]
>     *Sent:* Tuesday, January 25, 2011 7:47 AM
>     *To:* Rosenberg, Jonathan
>     *Cc:* 'Saverio Mascolo'; 'Stefan Håkansson LK'; 'Cullen Jennings';
>     tom_harper at logitech.com <mailto:tom_harper at logitech.com>; 'Justin
>     Uberti'; 'Harald Alvestrand'; rtc-web at alvestrand.no
>     <mailto:rtc-web at 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
> 
>     jdrosen at skype.net <mailto:jdrosen at skype.net> 
>                             http://www.skype.com
> 
>     jdrosen at jdrosen.net
>     <mailto:jdrosen at 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
> email:mascolo at poliba.it <mailto:email%3Amascolo at poliba.it>
>  
> 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.
> 
> 
> 
> _______________________________________________
> RTC-Web mailing list
> RTC-Web at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtc-web


More information about the RTC-Web mailing list