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

[Harald Alvestrand <[e-mail]>]

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" 
> <[e-mail]> 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:[e-mail]]
>         *Sent:* den 20 januari 2011  16:45
>         *To:* Henry Sinnreich
>         *Cc:* Stefan Håkansson LK; Cullen  Jennings; DISPATCH list;
>         [e-mail]
>         *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
>         <[e-mail]>  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"
>             <[e-mail]>
>             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: [e-mail]
>             >>  [mailto:[e-mail]] On  Behalf Of Cullen
>             Jennings
>             >> Sent: den 18 januari 2011  05:59
>             >> To: DISPATCH list
>             >> Cc: [e-mail]
>             >>  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
> [e-mail]
> http://www.alvestrand.no/mailman/listinfo/rtc-web