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

[Randell Jesup]

On 3/29/2012 5:09 AM, Michael Welzl wrote:
>
> On Mar 29, 2012, at 10:50 AM, Piers O'Hanlon wrote:

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

One thing I've realized, as we're now talking about this as well as 
other algorithms together - we need a name for what's covered in 
Harald's draft.  Harald; Stefan?  I'll refer to my similar extant 
algorithm (never published, more heuristic than Googles but very similar 
in approach) as the OJO algorithm if I mention it in posts here.

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

It is an interesting idea which had not really been considered before, 
and would obviously solve the congestion issue between rtcweb data 
channels and media channels.

There is an efficiency argument about RTP/SCTP/DTLS/(ICE)UDP compared to 
plain SRTP/UDP (keyed with DTLS-SRTP or SDES, a whole other religious 
war over in rtcweb).  It's not a huge impact on video, especially at 
higher bandwidths, but could be significant for audio-only calls.

In addition, some currently non-critical issues with SCTP would become 
more critical, such as an issue flagged about large reliable datagrams 
hogging the packet queues; and there might also be startup speed issues.

It would be a pretty major change at this point, I should note, but not 
(quite) impossible.

-- 
Randell Jesup
randell-ietf at jesup.org