How does unordered, unreliable SCTP implement congestion control in the browser (via webrtc)?

Question

According to RFC 3758, Stream Control Transmission Protocol Partial Reliability Extension, Section 1.3.4, "PR-SCTP employs the same congestion control and congestion avoidance for all data traffic, whether reliable or partially reliable - this is very desirable since SCTP enforces TCP-friendliness (unlike UDP.)"

How can an SCTP connection with unordered, unreliable message delivery implement congestion control? If congestion control relies on selectively acknowledged data to adjust the window size, and relies on dropped packets as an indicator of congestion in the network, won't this information be missing?

Is the congestion control different than when the message delivery is ordered and reliable? In comparison with a UDP socket, how much extra throttling/throughput restrictions will there be with an unreliable, unordered SCTP socket? Is it functionally equivalent to using a UDP socket?

Answer 1

My understanding is that there are two different kinds of sequence numbers:

• The "stream sequence number" -> that's for ordered streams
• The "transmission sequence number", a.k.a. TSN -> that's for congestion control

See RFC 2960, 1.3.4:

SCTP assigns a Transmission Sequence Number (TSN) to each user data fragment or unfragmented message. The TSN is independent of any stream sequence number assigned at the stream level. The receiving end acknowledges all TSNs received, even if there are gaps in the sequence. In this way, reliable delivery is kept functionally separate from sequenced stream delivery.

For congestion control, it does not really matter if the packets are transmitted reliably or ordered: you just want some statistics about how many packets were lost. SCTP will always ACK the packets, even if they are unordered and unreliable, such that it gets this statistics and can do congestion control.

That's different from UDP in that UDP does not do any kind of congestion control. So I would tend to think that it is not functionally equivalent to using a UDP socket. In terms of throughput, it feels like it would be closer to TCP (it will slow down when there is congestion). But the difference with TCP is that it will avoid "head-of-line blocking" (if I may call it like this), where packet 4 is blocked until packet 3 has been transmitted.