Hi Michael,<div><br></div><div>Some comments inline.</div><div><br></div><div>/Stefan</div><div><br><div class="gmail_quote">On Sun, Apr 1, 2012 at 11:17 AM, Michael Welzl <span dir="ltr"><<a href="mailto:michawe@ifi.uio.no">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 all,<br>
<br>
I've been giving this some more thought, and now think that it is a mistake to try to build a RTP-UDP-based congestion control mechanism with logic at the receiver, to plan when to send feedback and minimize it accordingly. The reason is that you want to sample the path often enough anyway, and that you may have SCTP operating on the data stream in parallel too. So that can give you a situation where you get a lot of ACKs all the time in SCTP, which will be ignored by the UDP-based algorithm, which is meanwhile struggling to reduce its own feedback. All this feedback is really only about the congestion status on the path anyway, i.e. SCTP ACKs give you all the information you need.<br>
</blockquote><div><br></div><div>I see the channel sampling frequency as one of the upsides with receive-side estimation, since you get a sample of the channel with every incoming packet without the need of the extra overhead of ACK packets. In addition, algorithms at the receive-side aren't limited to what we choose to feed back to the sender in the same way as a send-side algorithm. For instance at the receive-side we know exactly how late each packet is, if it is lost, if there's ECN, etc. We can make use of all of that, and all we have to feed back is our estimate of the available bandwidth.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
So my proposal would be:<br>
<br>
- use SCTP for everything<br>
- add per-stream congestion control to it, all on the sender side<br>
- use some other RTCWeb based signalling to negotiate the congestion control mechanism, in the style of DCCP<br>
- let all streams benefit from SCTP's ACKs; if we anyhow need to reduce the amount of feedback, we could use an appropriate means that's related to transport, and not the RTCP rule which has nothing to do with congestion control: ACK-CC, RFC 5690 would give a good basis for that.  (on a side note, when you run RTP over SCTP, you don't break any RTP rules regarding the amount of feedback I think...)<br>

<br>
This way, with all the congestion control logic happening on the sender side, it would be much easier to manage the joint congestion control behavior across streams - to control fairness among them, as desired by this group. Note that this can yield MUCH more benefits than meets the eye: e.g., if an ongoing transfer is already in Congestion Avoidance, a newly starting transfer across the same bottleneck (which you'll have to - correctly or not - assume for RTCWeb anyway) can skip Slow Start. In a prototypical example documented in:<br>
</blockquote><div><br></div><div>Not sure why it is easier to control the fairness among streams just because all the estimation happens at the send-side? In the receive-side approach a number for the total amount of available bandwidth between client A and client B with will be sent from from B to A. It is then up to client A to distribute that bandwidth among its streams. A newly starting transfer across the same bottleneck should share the same bandwidth, so as in your example it should be possible to skip slow start. Or maybe I'm missing your point?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Michael Welzl, Florian Niederbacher, Stein Gjessing: "Beneficial Transparent Deployment of SCTP: the Missing Pieces", IEEE GlobeCom 2011, 5-9 December 2011, Houston, Texas<br>
(fig.7)<br>
<br>
...we transferred two files across a testbed where we used the (at least then, very large) default Linux queue length (txqueuelen). The transfer time of the shorter file was reduced by almost 4 seconds, at no significant cost for the other transfer.<br>

<br>
In such a setup, a mechanism based on LEDBAT could perhaps be used (in a similar style as in the current proposal, using the TCP equation as a lower limit, and maybe tuning some parameters to be a bit more aggressive?), giving the benefit that LEDBAT has already been tested.<br>

<br>
What do y'all think?<br>
<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><br></div>