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@jesup.org