<br><br><div class="gmail_quote">On Tue, Apr 10, 2012 at 1:43 PM, Stefan Holmer <span dir="ltr"><<a href="mailto:stefan@webrtc.org">stefan@webrtc.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br></div><br><div class="gmail_quote"><div><div class="h5">On Sun, Apr 8, 2012 at 7:51 PM, Michael Welzl <span dir="ltr"><<a href="mailto:michawe@ifi.uio.no" target="_blank">michawe@ifi.uio.no</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
I changed the subject as we're really talking about SCTP, not DCCP here now. More below:<br>
<br>
[snip]<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Yes, this means an optional different ACKing behavior, with some<br>
congestion control logic on the receiver side, but only for the case of<br>
(partially) unreliable transfers. We're blowing up SCTP more and more<br>
here... still, this strikes me as a less blown up than having SCTP +<br>
DCCP, and possibly (note, only possibly) more efficient than having<br>
SCTP-for-data + some_new_cc-over-RTP/UDP<br>
</blockquote></blockquote>
<br>
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:<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
<br>
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.<br>
<br>
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.<br>
</blockquote>
<br>
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?<br>
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.<br>
<br>
<br>
On Apr 8, 2012, at 9:26 AM, Timothy B. Terriberry wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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).<br>
<br>
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.<br>
</blockquote>
<br>
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...<br>
</blockquote><div><br></div></div></div><div>Not sure which thread these comments fit in, so I chose this one. It may be worth noting that:</div><div><br></div><div>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.</div>
<div><br></div><div>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 </div>
</div></blockquote><div><br></div><div>Also, how much extra overhead are we talking about when ACKing every packet compared to having periodic REMB packets? I think there are a lot of use-cases which won't have any significant amount of RTCWEB data streams, and in those situations we only get the extra overhead from ACKing every packet, as there are no significant data streams to share ACKs with.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div class="im">
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cheers,<br>
Michael<br>
<br>
______________________________<u></u>_________________<br>
Rtp-congestion mailing list<br>
<a href="mailto:Rtp-congestion@alvestrand.no" target="_blank">Rtp-congestion@alvestrand.no</a><br>
<a href="http://www.alvestrand.no/mailman/listinfo/rtp-congestion" target="_blank">http://www.alvestrand.no/<u></u>mailman/listinfo/rtp-<u></u>congestion</a><br>
</blockquote></div></div><br>
</blockquote></div><br>