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