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

Tue Jan 25 16:38:20 CET 2011

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                          http://www.skype.com

jdrosen at jdrosen.net                        http://www.jdrosen.net

From: rtc-web-bounces at alvestrand.no [mailto:rtc-web-bounces at alvestrand.no] 
On Behalf Of Saverio Mascolo
Sent: Sunday, January 23, 2011 8:35 AM
To: Stefan Håkansson LK
Cc: Cullen Jennings; tom_harper at logitech.com; Justin Uberti; Harald 
Alvestrand; 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)

anyone knows what cc is used by skype?

we did this investigation for skype audio

http://c3lab.poliba.it/images/9/9b/Skype-tac10.pdf

and this one for video

http://c3lab.poliba.it/images/b/b7/Skype_comnet.pdf

-sm

On Sun, Jan 23, 2011 at 4:30 PM, Stefan Håkansson LK 
<stefan.lk.hakansson at ericsson.com> wrote:

Maybe we can work out the details along the way; I think I started the 
thread, and my purpose was to secure that congestion control of streams 
would be part of the solution, and to discuss if it should be in the 
charter.

Many mails discussing _how_ to rate control, and no mails against, means to 
me that people feel that congestion control should be supported.

Cullen, Harald: something to add to the charter?

//Stefan

  _____

From: rtc-web-bounces at alvestrand.no [mailto:rtc-web-bounces at alvestrand.no] 
On Behalf Of Peter Musgrave
Sent: den 23 januari 2011 13:14
To: Justin Uberti
Cc: tom_harper at logitech.com; rtc-web at alvestrand.no; Saverio Mascolo

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

Magor also uses a TFRC-based approach. The TFRC algorithm is very effective.

Peter Musgrave

On 2011-01-23, at 12:41 AM, Justin Uberti wrote:

Google Video Chat uses a TFRC-based algorithm for rate control.

On Sat, Jan 22, 2011 at 6:18 AM, Saverio Mascolo <saverio.mascolo at gmail.com> 
wrote:

On Fri, Jan 21, 2011 at 8:43 PM, Justin Uberti <juberti at google.com> wrote:

TFRC isn't perfect, but it seems to work pretty well in practice.

in practice where????

-sm

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.

I'm not aware of any other standards-track bandwidth estimation algorithms 
designed to work with RTP/UDP.

On Fri, Jan 21, 2011 at 9:46 AM, <tom_harper at logitech.com> wrote:

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-

tfrc seems scary/impractical at low latencies due to the following:
"The TFRC requirements of receiving feedback once per RTT can at times
  conflict with the AVP RTCP bandwidth constraints, particularly at
  small RTTs of 20 ms or less"
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.

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.

Are there any other inband schemes that are up in rfc at this point?

Tom

<graycol.gif>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

From: Stefan H嶡ansson LK <stefan.lk.hakansson at ericsson.com>
To: Justin Uberti <juberti at google.com>
Cc: Cullen Jennings <fluffy at cisco.com>, DISPATCH list <dispatch at ietf.org>, 
Henry Sinnreich <henry.sinnreich at gmail.com>, Harald Alvestrand 
<harald at alvestrand.no>, "rtc-web at alvestrand.no" <rtc-web at alvestrand.no>, 
Stephen Botzko <stephen.botzko at gmail.com>
Date: 01/21/2011 12:38 AM

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

Sent by: rtc-web-bounces at alvestrand.no

  _____

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.

  _____

From: Justin Uberti [mailto:juberti at google.com]
Sent: den 21 januari 2011 09:13
To: Stefan Håkansson LK
Cc: Harald Alvestrand; Henry Sinnreich; Cullen Jennings; 
rtc-web at alvestrand.no; DISPATCH list; Stephen Botzko
Subject: Re: [RTW] Rate control and codec adaption (Re: [dispatch] The 
charter formerly know as RTC-WEB take 3)

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.

There was a draft but it has been abandonded ( 
<http://tools.ietf.org/html/draft-ietf-avt-tfrc-profile-10> 
http://tools.ietf.org/html/draft-ietf-avt-tfrc-profile-10)

On Thu, Jan 20, 2011 at 11:50 PM, Stefan Håkansson LK < 
<mailto:stefan.lk.hakansson at ericsson.com> stefan.lk.hakansson at ericsson.com> 
wrote:

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

  _____

From: Harald Alvestrand [mailto: <mailto:harald at alvestrand.no> 
harald at alvestrand.no]
Sent: den 21 januari 2011 08:46
To: Henry Sinnreich
Cc: Stefan Håkansson LK; Stephen Botzko; Cullen Jennings; 
<mailto:rtc-web at alvestrand.no> rtc-web at alvestrand.no; DISPATCH list
Subject: Rate control and codec adaption (Re: [RTW] [dispatch] The charter 
formerly know as RTC-WEB take 3)

On 01/21/2011 12:06 AM, Henry Sinnreich wrote:

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

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.
Can you explain?

Changing the subject to content of thread....

are we reducing to a previously solved problem, or to a previously unsolved 
problem?
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).

Thanks, Henry

On 1/20/11 2:02 PM, "Stefan Håkansson LK" < 
<http://stefan.lk.hakansson@ericsson.com/> stefan.lk.hakansson at ericsson.com> 
wrote:

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.

Br,
Stefan

  _____

From: Stephen Botzko [ <mailto:stephen.botzko at gmail.com> 
mailto:stephen.botzko at gmail.com]
Sent: den 20 januari 2011 16:45
To: Henry Sinnreich
Cc: Stefan Håkansson LK; Cullen Jennings; DISPATCH list; 
<http://rtc-web@alvestrand.no/> rtc-web at alvestrand.no
Subject: Re: [dispatch] The charter formerly know as RTC-WEB take 3

>>>
How does this fit with adaptive codecs?
>>>
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.

>>>
Hint: codec selection matters, is actually critical to this effort.
>>>
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.

Stephen Botzko

On Thu, Jan 20, 2011 at 10:37 AM, Henry Sinnreich < 
<http://henry.sinnreich@gmail.com/> henry.sinnreich at gmail.com> wrote:

Hi Stefan,

> 2. The second one is about rate adaptation/congestion control. It is not
> mentioned at all. I don't know if it is needed, perhaps it is enough that
> RFC3550 (that is already pointed at) has a section about it, but I wanted 
> to
> highlight it.

How does this fit with adaptive codecs?
Hint: codec selection matters, is actually critical to this effort.

Thanks, Henry

On 1/20/11 3:52 AM, "Stefan Håkansson LK" < 
<http://stefan.lk.hakansson@ericsson.com/> stefan.lk.hakansson at ericsson.com>
wrote:

> Hi Cullen,
>
> two comments:
>
> 1. As requirements on the API are explicitly described, I thinke that 
> there
> should be a comment that the API must support media format negotiation.
> Proposal: "The API must enable media format negotiation and application
> influence over media format selection".
>
> 2. The second one is about rate adaptation/congestion control. It is not
> mentioned at all. I don't know if it is needed, perhaps it is enough that
> RFC3550 (that is already pointed at) has a section about it, but I wanted 
> to
> highlight it.
>
> Br,
> Stefan
>
>> -----Original Message-----
>> From:  <http://dispatch-bounces@ietf.org/> dispatch-bounces at ietf.org
>> [ <mailto:dispatch-bounces at ietf.org> mailto:dispatch-bounces at ietf.org] On 
>> Behalf Of Cullen Jennings
>> Sent: den 18 januari 2011 05:59
>> To: DISPATCH list
>> Cc:  <http://rtc-web@alvestrand.no/> rtc-web at alvestrand.no
>> Subject: [dispatch] The charter formerly know as RTC-WEB take 3
>>
>>
>> In my dispatch co-chair role, I tried to take all the
>> comments I had seen on the list about this charter and see if
>> I could address them in a new version of the charter. I
>> probably messed up in some places. There were some
>> conversation that did not seem to be converging so I did not
>> make any changes for theses. Have a read and if you think
>> something needs to be changed, propose text changes along
>> with the reasons why and we will keep the evolving this charter.
>>
>> Thanks
>> Cullen
>>
>> --------------------------------------------------------------
>> --------------------
>>
>> Version: 3
>>
>> Possible Names:
>>
>> RTCWEB
>> WEBRTC
>> STORM: Standardized Transport Oriented for Realtime Media
>> BURN: Browsers Using Realtime Media
>> WAVE: Web And Voice/Video Enablement
>> WAVVE: Web And Voice Video Enablement
>> REALTIME
>> WEBCOMM
>> WREALTIME
>> WEBTIME
>> WEBFLOWS
>> BRAVO Browser Realtime Audio and VideO
>> COBWEB COmmuication Between WEBclients
>> WHEELTIME
>>
>>
>>
>> Body:
>>
>> Many implementations have been made that use a Web browser to
>> support direct, interactive communications, including voice,
>> video, collaboration, and gaming. In these implementations,
>> the web server acts as the signaling path between these
>> applications, using locally significant identifiers to set up
>> the association. Up till now, such applications have
>> typically required the installation of plugins or
>> non-standard browser extensions. There is a desire to
>> standardize this functionality, so that this type of
>> application can be run in any compatible browser and allow
>> for high-quality real-time communications experiences within
>> the browser.
>>
>> Traditionally, the W3C has defined API and markup languages
>> such as HTML that work in conjunction with with the IETF over
>> the wire protocols such as HTTP to allow web browsers to
>> display media that does not have real time interactive
>> constraints with another human.
>>
>> The W3C and IETF plan to collaborate together in their
>> traditional way to meet the evolving needs of browsers.
>> Specifically the IETF will provide a set of on the wire
>> protocols, including RTP, to meet the needs on interactive
>> communications, and the W3C will define the API and markup to
>> allow web application developers to control the on the wire
>> protocols. This will allow application developers to write
>> applications that run in a browser and facilitate interactive
>> communications between users for voice and video
>> communications, collaboration, and gaming.
>>
>> This working group will select and define a minimal set of
>> protocols that will enable browsers to:
>>
>> * have interactive real time voice and video pairwise be

_______________________________________________
RTC-Web mailing list
 <mailto:RTC-Web at alvestrand.no> RTC-Web at alvestrand.no
 <http://www.alvestrand.no/mailman/listinfo/rtc-web> 
http://www.alvestrand.no/mailman/listinfo/rtc-web

_______________________________________________
RTC-Web mailing list
 <mailto:RTC-Web at alvestrand.no> RTC-Web at alvestrand.no
 <http://www.alvestrand.no/mailman/listinfo/rtc-web> 
http://www.alvestrand.no/mailman/listinfo/rtc-web

_______________________________________________
RTC-Web mailing list
RTC-Web at alvestrand.no
http://www.alvestrand.no/mailman/listinfo/rtc-web

_______________________________________________
RTC-Web mailing list
RTC-Web at alvestrand.no
http://www.alvestrand.no/mailman/listinfo/rtc-web

_______________________________________________
RTC-Web mailing list
RTC-Web at alvestrand.no
http://www.alvestrand.no/mailman/listinfo/rtc-web

-- 
Prof. Saverio Mascolo
Dipartimento di Elettrotecnica ed Elettronica
Politecnico di Bari
Via Orabona 4, 70125 Bari Italy
Tel. +39 080 5963621 <tel:+390805963621>
Fax. +39 080 5963410 <tel:+390805963410>
email:mascolo at poliba.it <mailto:email%3Amascolo at poliba.it>

http://c3lab.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

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/rtc-web/attachments/20110125/30f3912c/attachment-0001.html>