TFRC isn't perfect, but it seems to work pretty well in practice. The RTP extension header overhead of 12 bytes per packet is fairly nominal (1%) at today's video bitrates, as is the cost of the RTCP feedback message.<div>
<br></div><div>I'm not aware of any other standards-track bandwidth estimation algorithms designed to work with RTP/UDP.</div><div><div><div><br><div class="gmail_quote">On Fri, Jan 21, 2011 at 9:46 AM, <span dir="ltr"><<a href="mailto:tom_harper@logitech.com">tom_harper@logitech.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div>
<p>It seems to me neither avpf or tfrc is fully perfect- on the whole tfrc seems to be better than avpf in terms of constant measurement of the connection- <br>
<br>
tfrc seems scary/impractical at low latencies due to the following:<br>
<tt><font size="4">"The TFRC requirements of receiving feedback once per RTT can at times<br>
conflict with the AVP RTCP bandwidth constraints, particularly at<br>
small RTTs of 20 ms or less</font></tt>"<br>
and the fact that it has to be attached as an extension header to every data packet seems like more overhead than is needed, but others opinions may differ on this.<br>
<br>
We support avpf as defined 5104/4585, but prefer not to use it as in some scenarios we have run into the rtcp bandwidth cap- and then you get no feedback at all in a timely manner.<br>
<br>
Are there any other inband schemes that are up in rfc at this point?<br>
<br>
Tom<br>
<br>
<br>
<br>
<img width="16" height="16" src="cid:1__=07BBF28CDFCC32248f9e8a93df9@logitech.com" border="0" alt="Inactive hide details for Stefan H嶡ansson LK ---01/21/2011 12:38:33 AM---Isn't it so that with the AVPF profile you can actua"><font color="#424282">Stefan H嶡ansson LK ---01/21/2011 12:38:33 AM---Isn't it so that with the AVPF profile you can actually sent RTCP when there is a need (even if a tr</font><br>
<br>
<font size="2" color="#5F5F5F">From: </font><font size="2">Stefan H嶡ansson LK <<a href="mailto:stefan.lk.hakansson@ericsson.com" target="_blank">stefan.lk.hakansson@ericsson.com</a>></font><br>
<font size="2" color="#5F5F5F">To: </font><font size="2">Justin Uberti <<a href="mailto:juberti@google.com" target="_blank">juberti@google.com</a>></font><br>
<font size="2" color="#5F5F5F">Cc: </font><font size="2">Cullen Jennings <<a href="mailto:fluffy@cisco.com" target="_blank">fluffy@cisco.com</a>>, DISPATCH list <<a href="mailto:dispatch@ietf.org" target="_blank">dispatch@ietf.org</a>>, Henry Sinnreich <<a href="mailto:henry.sinnreich@gmail.com" target="_blank">henry.sinnreich@gmail.com</a>>, Harald Alvestrand <<a href="mailto:harald@alvestrand.no" target="_blank">harald@alvestrand.no</a>>, "<a href="mailto:rtc-web@alvestrand.no" target="_blank">rtc-web@alvestrand.no</a>" <<a href="mailto:rtc-web@alvestrand.no" target="_blank">rtc-web@alvestrand.no</a>>, Stephen Botzko <<a href="mailto:stephen.botzko@gmail.com" target="_blank">stephen.botzko@gmail.com</a>></font><br>
<font size="2" color="#5F5F5F">Date: </font><font size="2">01/21/2011 12:38 AM</font></p><div class="im"><br>
<font size="2" color="#5F5F5F">Subject: </font><font size="2">Re: [RTW] Rate control and codec adaption (Re: [dispatch] The charter formerly know as RTC-WEB take 3)</font><br>
</div><font size="2" color="#5F5F5F">Sent by: </font><font size="2"><a href="mailto:rtc-web-bounces@alvestrand.no" target="_blank">rtc-web-bounces@alvestrand.no</a></font><br>
<hr width="100%" size="2" align="left" noshade style="color:#8091A5"><div><div></div><div class="h5"><br>
<br>
<br>
<font color="#0000FF" face="Arial">Isn't it so that with the AVPF profile you can actually sent RTCP when there is a need (even if a transmission is not due)? This way you can actually react fast. </font><br>
<br>
<hr width="100%" size="2" align="left"><b><font face="Tahoma">From:</font></b><font face="Tahoma"> Justin Uberti [</font><font face="Tahoma"><a href="mailto:juberti@google.com" target="_blank">mailto:juberti@google.com</a></font><font face="Tahoma">] </font><b><font face="Tahoma"><br>
Sent:</font></b><font face="Tahoma"> den 21 januari 2011 09:13</font><b><font face="Tahoma"><br>
To:</font></b><font face="Tahoma"> Stefan Håkansson LK</font><b><font face="Tahoma"><br>
Cc:</font></b><font face="Tahoma"> Harald Alvestrand; Henry Sinnreich; Cullen Jennings; <a href="mailto:rtc-web@alvestrand.no" target="_blank">rtc-web@alvestrand.no</a>; DISPATCH list; Stephen Botzko</font><b><font face="Tahoma"><br>
Subject:</font></b><font face="Tahoma"> Re: [RTW] Rate control and codec adaption (Re: [dispatch] The charter formerly know as RTC-WEB take 3)</font><font size="4"><br>
</font><br>
<font size="4">RTCP typically isn't sent frequently enough to allow for real-time adjustments in bitrate. TFRC provides a nice mechanism for controlling bitrate in real-time, but the work to apply TFRC to RTP has not yet been codified into a standard. </font><br>
<br>
<font size="4">There was a draft but it has been abandonded (</font><a href="http://tools.ietf.org/html/draft-ietf-avt-tfrc-profile-10" target="_blank"><u><font size="4" color="#0000FF">http://tools.ietf.org/html/draft-ietf-avt-tfrc-profile-10</font></u></a><font size="4">)<br>
</font><br>
<font size="4">On Thu, Jan 20, 2011 at 11:50 PM, Stefan Håkansson LK <</font><a href="mailto:stefan.lk.hakansson@ericsson.com" target="_blank"><u><font size="4" color="#0000FF">stefan.lk.hakansson@ericsson.com</font></u></a><font size="4">> wrote:</font>
<ul><font color="#0000FF" face="Arial">My view: we are discussing a problem already solved! The common procedure would be to use info in the RTCP reports from the receiving end to change the transmitted bit rate (if change is required). </font><br>
<br>
<hr width="100%" size="2" align="left"><b><font face="Tahoma">From:</font></b><font face="Tahoma"> Harald Alvestrand [mailto:</font><a href="mailto:harald@alvestrand.no" target="_blank"><u><font color="#0000FF" face="Tahoma">harald@alvestrand.no</font></u></a><font face="Tahoma">] </font><b><font face="Tahoma"><br>
Sent:</font></b><font face="Tahoma"> den 21 januari 2011 08:46</font><b><font face="Tahoma"><br>
To:</font></b><font face="Tahoma"> Henry Sinnreich</font><b><font face="Tahoma"><br>
Cc:</font></b><font face="Tahoma"> Stefan Håkansson LK; Stephen Botzko; Cullen Jennings; </font><a href="mailto:rtc-web@alvestrand.no" target="_blank"><u><font color="#0000FF" face="Tahoma">rtc-web@alvestrand.no</font></u></a><font face="Tahoma">; DISPATCH list</font><b><font face="Tahoma"><br>
Subject:</font></b><font face="Tahoma"> Rate control and codec adaption (Re: [RTW] [dispatch] The charter formerly know as RTC-WEB take 3)</font><font size="4"><br>
</font><br>
<font size="4">On 01/21/2011 12:06 AM, Henry Sinnreich wrote: </font>
<ul>
<ul><font size="4" face="Calibri">></font><font size="4" color="#0000FE" face="Arial">Minor comment: I think all codecs that have been discussed (except for G.711) are adaptive in the sense that their bitrate can be adapted.</font><font size="4" face="Calibri"><br>
<br>
It is not clear to me how to avoid the codec adaptation mechanism fighting the rate control mechanism, without some guidance in the standard for developers.<br>
Can you explain?</font></ul>
</ul>
<font size="4">Changing the subject to content of thread....<br>
<br>
are we reducing to a previously solved problem, or to a previously unsolved problem?<br>
I don't see how this problem actually differs from the one that people will have when operating RTP under TFRC (draft-ietf-avt-tfrc-profile-10).<br>
</font>
<ul>
<ul><font size="4" face="Calibri"><br>
Thanks, Henry<br>
<br>
<br>
On 1/20/11 2:02 PM, "Stefan Håkansson LK" <</font><a href="http://stefan.lk.hakansson@ericsson.com/" target="_blank"><u><font size="4" color="#0000FF" face="Calibri">stefan.lk.hakansson@ericsson.com</font></u></a><font size="4" face="Calibri">> wrote:<br>
</font>
<ul>
<ul><font size="4" color="#0000FF" face="Arial">Minor comment: I think all codecs that have been discussed (except for G.711) are adaptive in the sense that their bitrate can be adapted.</font><font size="4" face="Calibri"><br>
</font><font size="4" color="#0000FF" face="Arial"><br>
Br,<br>
Stefan</font><font size="4" face="Calibri"><br>
</font>
<ul>
<ul><font size="4" face="Calibri"><br>
<br>
</font><hr width="100%" size="2" align="left"><b><font size="4" face="Tahoma">From:</font></b><font size="4" face="Tahoma"> Stephen Botzko [</font><a href="mailto:stephen.botzko@gmail.com" target="_blank"><u><font size="4" color="#0000FF" face="Tahoma">mailto:stephen.botzko@gmail.com</font></u></a><font size="4" face="Tahoma">] </font><b><font size="4" face="Tahoma"><br>
Sent:</font></b><font size="4" face="Tahoma"> den 20 januari 2011 16:45</font><b><font size="4" face="Tahoma"><br>
To:</font></b><font size="4" face="Tahoma"> Henry Sinnreich</font><b><font size="4" face="Tahoma"><br>
Cc:</font></b><font size="4" face="Tahoma"> Stefan Håkansson LK; Cullen Jennings; DISPATCH list; </font><a href="http://rtc-web@alvestrand.no/" target="_blank"><u><font size="4" color="#0000FF" face="Tahoma">rtc-web@alvestrand.no</font></u></a><b><font size="4" face="Tahoma"><br>
Subject:</font></b><font size="4" face="Tahoma"> Re: [dispatch] The charter formerly know as RTC-WEB take 3</font><font size="4" face="Calibri"><br>
<br>
<br>
>>><br>
How does this fit with adaptive codecs?<br>
>>><br>
Just because some codecs can adapt doesn't mean rate adaptation/congestion control should be left out of the scope. I think it needs to be considered.<br>
<br>
>>><br>
Hint: codec selection matters, is actually critical to this effort.<br>
>>><br>
Codec selection does matter, but I am not convinced that mandatory codecs need to be in the RFCs. I believe market forces are sufficient - SIP itself is one proof point.<br>
<br>
Stephen Botzko<br>
<br>
<br>
<br>
On Thu, Jan 20, 2011 at 10:37 AM, Henry Sinnreich <</font><a href="http://henry.sinnreich@gmail.com/" target="_blank"><u><font size="4" color="#0000FF" face="Calibri">henry.sinnreich@gmail.com</font></u></a><font size="4" face="Calibri">> wrote:<br>
</font>
<ul>
<ul><font size="4" face="Calibri">Hi Stefan,<br>
<br>
<br>
> 2. The second one is about rate adaptation/congestion control. It is not<br>
> mentioned at all. I don't know if it is needed, perhaps it is enough that<br>
> RFC3550 (that is already pointed at) has a section about it, but I wanted to<br>
> highlight it.<br>
<br>
How does this fit with adaptive codecs?<br>
Hint: codec selection matters, is actually critical to this effort.<br>
<br>
Thanks, Henry<br>
<br>
<br>
On 1/20/11 3:52 AM, "Stefan Håkansson LK" <</font><a href="http://stefan.lk.hakansson@ericsson.com/" target="_blank"><u><font size="4" color="#0000FF" face="Calibri">stefan.lk.hakansson@ericsson.com</font></u></a><font size="4" face="Calibri">><br>
wrote:<br>
<br>
<br>
<br>
<br>
> Hi Cullen,<br>
><br>
> two comments:<br>
><br>
> 1. As requirements on the API are explicitly described, I thinke that there<br>
> should be a comment that the API must support media format negotiation.<br>
> Proposal: "The API must enable media format negotiation and application<br>
> influence over media format selection".<br>
><br>
> 2. The second one is about rate adaptation/congestion control. It is not<br>
> mentioned at all. I don't know if it is needed, perhaps it is enough that<br>
> RFC3550 (that is already pointed at) has a section about it, but I wanted to<br>
> highlight it.<br>
><br>
> Br,<br>
> Stefan<br>
><br>
>> -----Original Message-----<br>
>> From: </font><a href="http://dispatch-bounces@ietf.org/" target="_blank"><u><font size="4" color="#0000FF" face="Calibri">dispatch-bounces@ietf.org</font></u></a><font size="4" face="Calibri"><br>
>> [</font><a href="mailto:dispatch-bounces@ietf.org" target="_blank"><u><font size="4" color="#0000FF" face="Calibri">mailto:dispatch-bounces@ietf.org</font></u></a><font size="4" face="Calibri">] On Behalf Of Cullen Jennings<br>
>> Sent: den 18 januari 2011 05:59<br>
>> To: DISPATCH list<br>
>> Cc: </font><a href="http://rtc-web@alvestrand.no/" target="_blank"><u><font size="4" color="#0000FF" face="Calibri">rtc-web@alvestrand.no</font></u></a><font size="4" face="Calibri"><br>
>> Subject: [dispatch] The charter formerly know as RTC-WEB take 3<br>
>><br>
>><br>
>> In my dispatch co-chair role, I tried to take all the<br>
>> comments I had seen on the list about this charter and see if<br>
>> I could address them in a new version of the charter. I<br>
>> probably messed up in some places. There were some<br>
>> conversation that did not seem to be converging so I did not<br>
>> make any changes for theses. Have a read and if you think<br>
>> something needs to be changed, propose text changes along<br>
>> with the reasons why and we will keep the evolving this charter.<br>
>><br>
>> Thanks<br>
>> Cullen<br>
>><br>
>> --------------------------------------------------------------<br>
>> --------------------<br>
>><br>
>> Version: 3<br>
>><br>
>> Possible Names:<br>
>><br>
>> RTCWEB<br>
>> WEBRTC<br>
>> STORM: Standardized Transport Oriented for Realtime Media<br>
>> BURN: Browsers Using Realtime Media<br>
>> WAVE: Web And Voice/Video Enablement<br>
>> WAVVE: Web And Voice Video Enablement<br>
>> REALTIME<br>
>> WEBCOMM<br>
>> WREALTIME<br>
>> WEBTIME<br>
>> WEBFLOWS<br>
>> BRAVO Browser Realtime Audio and VideO<br>
>> COBWEB COmmuication Between WEBclients<br>
>> WHEELTIME<br>
>><br>
>><br>
>><br>
>> Body:<br>
>><br>
>> Many implementations have been made that use a Web browser to<br>
>> support direct, interactive communications, including voice,<br>
>> video, collaboration, and gaming. In these implementations,<br>
>> the web server acts as the signaling path between these<br>
>> applications, using locally significant identifiers to set up<br>
>> the association. Up till now, such applications have<br>
>> typically required the installation of plugins or<br>
>> non-standard browser extensions. There is a desire to<br>
>> standardize this functionality, so that this type of<br>
>> application can be run in any compatible browser and allow<br>
>> for high-quality real-time communications experiences within<br>
>> the browser.<br>
>><br>
>> Traditionally, the W3C has defined API and markup languages<br>
>> such as HTML that work in conjunction with with the IETF over<br>
>> the wire protocols such as HTTP to allow web browsers to<br>
>> display media that does not have real time interactive<br>
>> constraints with another human.<br>
>><br>
>> The W3C and IETF plan to collaborate together in their<br>
>> traditional way to meet the evolving needs of browsers.<br>
>> Specifically the IETF will provide a set of on the wire<br>
>> protocols, including RTP, to meet the needs on interactive<br>
>> communications, and the W3C will define the API and markup to<br>
>> allow web application developers to control the on the wire<br>
>> protocols. This will allow application developers to write<br>
>> applications that run in a browser and facilitate interactive<br>
>> communications between users for voice and video<br>
>> communications, collaboration, and gaming.<br>
>><br>
>> This working group will select and define a minimal set of<br>
>> protocols that will enable browsers to:<br>
>><br>
>> * have interactive real time voice and video pairwise be</font></ul>
</ul>
</ul>
</ul>
</ul>
</ul>
<tt><font size="4"><br>
_______________________________________________<br>
RTC-Web mailing list<br>
</font></tt><a href="mailto:RTC-Web@alvestrand.no" target="_blank"><tt><u><font size="4" color="#0000FF">RTC-Web@alvestrand.no</font></u></tt></a><tt><font size="4"><br>
</font></tt><a href="http://www.alvestrand.no/mailman/listinfo/rtc-web" target="_blank"><tt><u><font size="4" color="#0000FF">http://www.alvestrand.no/mailman/listinfo/rtc-web</font></u></tt></a><tt><font size="4"><br>
</font></tt></ul>
</ul>
<br>
<font size="4"><br>
_______________________________________________<br>
RTC-Web mailing list</font><u><font size="4" color="#0000FF"><br>
</font></u><a href="mailto:RTC-Web@alvestrand.no" target="_blank"><u><font size="4" color="#0000FF">RTC-Web@alvestrand.no</font></u></a><u><font size="4" color="#0000FF"><br>
</font></u><a href="http://www.alvestrand.no/mailman/listinfo/rtc-web" target="_blank"><u><font size="4" color="#0000FF">http://www.alvestrand.no/mailman/listinfo/rtc-web</font></u></a><font size="4"><br>
</font></ul>
<tt>_______________________________________________<br>
RTC-Web mailing list<br>
<a href="mailto:RTC-Web@alvestrand.no" target="_blank">RTC-Web@alvestrand.no</a><br>
</tt><tt><a href="http://www.alvestrand.no/mailman/listinfo/rtc-web" target="_blank">http://www.alvestrand.no/mailman/listinfo/rtc-web</a></tt><tt><br>
</tt><br>
</div></div><p></p></div><br>_______________________________________________<br>
RTC-Web mailing list<br>
<a href="mailto:RTC-Web@alvestrand.no">RTC-Web@alvestrand.no</a><br>
<a href="http://www.alvestrand.no/mailman/listinfo/rtc-web" target="_blank">http://www.alvestrand.no/mailman/listinfo/rtc-web</a><br>
<br></blockquote></div><br></div></div></div>