[R-C] DCCP as an RTCWEB option (Re: Modular Congestion Control in rtcweb)

[Michael Welzl]

On Mar 29, 2012, at 10:50 AM, Piers O'Hanlon wrote:

>
> On 29 Mar 2012, at 10:31, Michael Welzl wrote:
>
>> SCTP provides that, but on a per-connection (not per-stream) basis  
>> (if I understood him correctly), and negotiation of congestion  
>> controls is not a part of the protocol spec. Given that SCTP also  
>> provides partial reliability (which can be more useful for  
>> streaming media than DCCP's total absence of reliability too!),  
>> would it not be the most efficient way ahead to:
>> 1) extend SCTP to have pluggable congestion control per stream and  
>> negotiate that,
>> 2) incorporate that in the SCTP userland implementation,
>> 3) use SCTP as the transport for everything??
>>
> Sure (which is what I suggested) - since there seems to be limited  
> concern about the fact that SCTP spec actually provides for  
> pluggability, though this will need to specified somewhere.....

- sorry for missing that this is what you had meant; agreed, this  
would have to be specified.


> I think Randell suggested on the Jabber in RTCweb that he'd like to  
> see a delayed based TCP like congestion control for SCTP (e.g.  
> CxTCP) - though it may make more sense to use LEDBAT as cxTCP isn't  
> primarily focused on low delay operation.

A LEDBAT-derivative might not fit the RTP requirements, I think. But  
yes, I wondered if basing a new congestion control mechanism off  
LEDBAT (e.g., using LEDBAT with the TCP equation as a minimum rate,  
just like proposed in the "google congestion control algorithm")  
wouldn't have been a better approach than to design a whole new  
mechanism. Just not sure if it's doable, as you want to ACK less, and  
have some logic on the receiver side for that.


> This is important as delayed based media congestion control is  
> unable to provide for low delay if it is competing directly with  
> normal loss-based TCP.
>
> The questions are then about how one puts (S?)RTP into SCTP....

Yes, this means an optional different ACKing behavior, with some  
congestion control logic on the receiver side, but only for the case  
of (partially) unreliable transfers. We're blowing up SCTP more and  
more here... still, this strikes me as a less blown up than having  
SCTP + DCCP, and possibly (note, only possibly) more efficient than  
having SCTP-for-data + some_new_cc-over-RTP/UDP

Cheers,
Michael