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@skype.net http://www.skype.com
jdrosen@jdrosen.net http://www.jdrosen.net
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@skype.net http://www.skype.com jdrosen@jdrosen.net http://www.jdrosen.net From: Matthew Kaufman [mailto:matthew.kaufman@skype.net] Sent: Tuesday, January 25, 2011 7:47 AM To: Rosenberg, Jonathan Cc: 'Saverio Mascolo'; 'Stefan Håkansson LK'; 'Cullen Jennings'; tom_harper@logitech.com; 'Justin Uberti'; 'Harald Alvestrand'; 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 jdrosen@skype.net http://www.skype.com jdrosen@jdrosen.net http://www.jdrosen.net
Part of the unwritten contract of a browser is you can go to an evil web site, you might have blink text on you screen but the browser protects you from anything bad happening to your computer, network, internet, small fluffy animals, etc. I like the idea of being able to improve the experience via something in the Javascript but I would expect the browser to enforce a minimal level of congestion safety. I would sort of expect the transports ADs to insist on something that was "safe". (and don't ask me what safe means but I know it when I see it) Cullen On Jan 25, 2011, at 7:46 , Matthew Kaufman wrote:
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@skype.net http://www.skype.com jdrosen@jdrosen.net http://www.jdrosen.net
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html
participants (3)
-
Cullen Jennings -
Matthew Kaufman -
Rosenberg, Jonathan