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

[Stefan Holmer]

On Tue, Apr 10, 2012 at 2:28 PM, Michael Tuexen <
Michael.Tuexen at lurchi.franken.de> wrote:

> On Apr 10, 2012, at 1:43 PM, Stefan Holmer wrote:
>
> >
> >
> > On Sun, Apr 8, 2012 at 7:51 PM, Michael Welzl <michawe at ifi.uio.no>
> wrote:
> > Hi,
> >
> > I changed the subject as we're really talking about SCTP, not DCCP here
> now. More below:
> >
> > [snip]
> >
> >
> > 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
> >
> > Note that the above paragraph by me captures a view that has meanwhile
> evolved: I now think that there should probably be only one single
> congestion control instance for everything (and then it wouldn't matter
> much whether it's on the sender or receiver side). With that in mind, I'll
> answer below:
> >
> >
> > 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?
> > 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.
> >
> >
> > 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...
> >
> > Not sure which thread these comments fit in, so I chose this one. It may
> be worth noting that:
> >
> > a. Delayed ACKs will make a send-side algorithm slower at reacting to
> increased delay upon congestion. This may be possible to get around by
> having some mechanism at the receive-side as well for detecting congestion
> and thereby force the ACK to be sent.
> The is an extension (implemented in Linux and FreeBSD), described in
> http://tools.ietf.org/html/draft-tuexen-tsvwg-sctp-sack-immediately-08
> which allows the sender to request a SACK not being delayed.
>
> Best regards
> Michael
>

Right, and by doing so you get more frequent ACKs and more overhead. I
wanted to make it clear that there's a trade-off between the amount of
overhead and the reaction time here.


> >
> > b. Lost ACKs may introduce uncertainty for the send-side algorithm,
> which will never be a problem for a recieve-side algorithm. You can reduce
> the uncertainty by having something like an ACK sequence number in each ACK
> message, but you have still lost the delay information contained in the
> lost ACK. Maybe something like this already exists in SCTP?
> >
> >
> > Cheers,
> > Michael
> >
> > _______________________________________________
> > Rtp-congestion mailing list
> > Rtp-congestion at alvestrand.no
> > http://www.alvestrand.no/mailman/listinfo/rtp-congestion
> >
> > _______________________________________________
> > Rtp-congestion mailing list
> > Rtp-congestion at alvestrand.no
> > http://www.alvestrand.no/mailman/listinfo/rtp-congestion
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/rtp-congestion/attachments/20120410/9639a6ab/attachment-0001.html>