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

[Randell Jesup]

On 4/8/2012 1:51 PM, Michael Welzl wrote:

>> 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.
>
> I don't see why (a potentially adapted) SCTP couldn't be made to always
> fragment packets beyond a certain size to avoid that hogging problem.
> And I don't understand how that would become more critical?

There's already an issue with large datagrams (which are already 
fragmented by SCTP) monopolizing the stack queues in certain cases. 
However, currently this only affects other data streams and not media 
(which is very sensitive to even temporary blocking).

> As for startup speed, I think that this is not true (au contraire! no
> need for slow starting into a network that's already used by another
> stream) if we have only one congestion control instance.

I was referring to call startup speed.  Right now we don't need to start 
SCTP to start media.

> On Apr 8, 2012, at 9:26 AM, Timothy B. Terriberry wrote:
>
>> Keep in mind that one of the arguments against the shim approach to
>> multiple RTP sessions on a single port was that it would break all
>> existing traffic management software at gateways, firewalls, etc.,
>> that tries to inspect RTP/SRTP packets. The same would be true of
>> RTP/SCTP/DTLS/UDP, except moreso (as you would no longer even be able
>> to get at the fields that are normally unencrypted in an SRTP session,
>> regardless of your ability to upgrade software on the gateways and
>> firewalls).
>>
>> To me this is at least as big a disadvantage as the efficiency
>> argument, though adding that many more bytes of overhead to on the
>> order of 100 packets a second is already a pretty big disadvantage.
>
> I don't know much about and have no strong opinion about that first
> argument, but regarding the overhead, note that there is significant
> overhead in the other variant too: you have SCTP data traffic causing
> receiver-side ACKs that convey pretty much the same information as RTCP
> feedback, but both streams mutually ignore each other...

Don't assume that there's lots of data traffic - often (usually) there 
will be little or no data traffic, so imposing overhead on every media 
packet is a significant hit, especially in a low-bandwidth situation.

SRTP over UDP is already ~44-50 bytes (IPv4, depending on hash tag 
length - RTP over UDP is 40); RTP over SCTP over DTLS over UDP is ... a 
bunch; I don't have time to calculate it right now.  And for a 
low-bandwidth audio-only call the payload could be little as 10 or 
15Kbps over 50 packets/sec.

-- 
Randell Jesup
randell-ietf at jesup.org