[R-C] RTCWEB Congestion Control Standardization

Colin Perkins csp at csperkins.org
Tue Oct 11 17:59:37 CEST 2011


On 10 Oct 2011, at 10:22, Magnus Westerlund wrote:
> I want to lift an important non-technical topic for discussion. Namely,
> what is needed in the specifications and how to get that to happen.
> 
> 
> It is clear that RTCWEB can't be the home to specify any new congestion control algorithms or procedures. That needs to be defined elsewhere.
> 
> Looking at what is available from a specification point of view, I think the only that is fully specified for RTP is TFRC in DCCP.

There's a TCP-like CCID for DCCP that could be used too, if we went down that route. TFWC could be written up as a CCID fairly easily too, as it's reasonably well specified. 

One of the strengths of DCCP is that it made the choice of congestion control algorithm something that is negotiated at connection setup time. Whether or not we adopt DCCP as a lower-layer protocol, it'd be valuable to put in the necessary hooks to negotiate different congestion control, since whatever we develop now is unlikely to be the final answer in this space. 

> The technical discussion appears to be desiring something else. Thus I
> think we need to have the discussion of how to get that written up in a
> specification eventually. What is the plan here? From my perspective we
> will need something that is acceptable to get the RTCWEB's RTP usage
> specification through IESG. Especially as we have identified clear
> security threats to no having congestion control in the browser part
> preventing significant over uses.
> 
> So what are our alternative here?
> 
> 1) Pick TFRC for now while developing something better? Possibly ensure
> that the RTP mapping gets published in a reasonable time frame.
> 
> 2) Try to write clear requirements on the implementation, but no
> specification and hopes that goes through?
> 
> 3) Develop something and delay the publication of any part that needs
> this until it is done?
> 
> 4) ?
> 
> Regarding 3), I don't see how that is going to complete in less than 2
> more likely 3 years. Spin up a TSV WG, develop a solution. Simulate and
> discuss corner cases for a while before getting good enough out.
> 
> So what are your views on this issue?

Requirements, with a specification developing in parallel if none of the existing solutions are sufficient (and I agree that they're probably not suitable as they stand).

-- 
Colin Perkins
http://csperkins.org/





More information about the Rtp-congestion mailing list