[RTW] Rate control and codec adaption (Re: [dispatch] The charter formerly know as RTC-WEB take 3)
tom_harper at logitech.com
tom_harper at logitech.com
Fri Jan 21 18:46:59 CET 2011
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
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)
On Thu, Jan 20, 2011 at 11:50 PM, Stefan Håkansson LK <
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:harald at alvestrand.no]
Sent: den 21 januari 2011 08:46
To: Henry Sinnreich
Cc: Stefan Håkansson LK; Stephen Botzko; Cullen Jennings;
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" <
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
]
Sent: den 20 januari 2011 16:45
To: Henry Sinnreich
Cc: Stefan Håkansson LK; Cullen Jennings; DISPATCH
list; 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 <
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" <
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: 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: 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
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/rtc-web/attachments/20110121/5973ff06/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://www.alvestrand.no/pipermail/rtc-web/attachments/20110121/5973ff06/attachment-0001.gif>
More information about the RTC-Web
mailing list