Michael, Clearly the SCTP ACK do provide the sender with information. It is clearly possible to use ACK based schemes. However, I think there are other factors that makes SCTP as currently defined unsuitable. My main question to you regarding running RTP over SCTP would be how you would tackle what I perceive as one of the main issues when running real-time interactive media over congestion control mechanisms like TCP and TFRC. Namely the clocking of the packets. To maintain timely and minimal delay the media sender will need to be able to clock out the packets for each audio or video frame following the sampling intervals basically. The issue with TFRC and TCP is that they dictate when the packet is to be sent. Every time the CC algorithm doesn't grant immediately the right to transmission you do introduce end-to-end jitter already at pre-sending stage. This is connected to the issue that once you have encoded the content into some format and bit-rate it represents significant work to go back and change that. Thus any control signal to reduce the transmission rate that arrive later than the time of starting encoding is to late to consider in this frame. You need to send that out and adjust in the next video or audio frame the amount of data produced. You get a similar issue with how to deal with video streams that can be extremely bursty due to both application needs of I-frames and simply content properties (large movements or zoom etc). To stay within delay budget and not introduce significant playout jitter you can't really smooth the burst longer than approximately one video frame interval, something on the range of 16.67 (60 fps) - 100 (10 fps) ms. A video stream that is being transmitted over TCP or for that matter SCTP that has this behavior will in most situation blow a tight end-to-end delay budget. And when I say end to end I mean from video capture until video display. Using TCP or SCTP works fine for less time critical task, streaming clearly works fine, but there using a buffer of at least 2 seconds allows for more than sufficient smoothing of the variations both in the CC algorithm and in the encoded content.
From my perspective the toughest issues with congestion control for RTP are the following:
1) Tight and very low end-to-end delay requirements making introduction of additional delay by the congestion control very questionable. For really excellent quality the delay e2e must be below 200 ms, ok quality is achievable over e2e delays up to 400-500 ms. Beyond that you aren't really considering it being interactive. 2) Extremely bursty media sources, like video that can have more than a factor 10 in frame by frame variations in amount of data to transmit if you are to maintain the same video quality between frames. 3) An extremely nasty flow startup issue. For video the first frame is the most heavy. At the same time it is critical to get through. And in most cases you have no information about what introducing that amount of data into the network will do. In addition due to intra-prediction if one looses part of this image you will have significant quality reduction in many video frames following the first one. Just trying to make clear what the problem is. Cheers Magnus On 2012-04-04 00:12, Michael Welzl wrote:
On Apr 3, 2012, at 10:16 AM, Stefan Holmer wrote:
Hi Michael,
Some comments inline.
/Stefan
On Sun, Apr 1, 2012 at 11:17 AM, Michael Welzl <michawe@ifi.uio.no> wrote: Hi all,
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.
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.
Okay, I understand that view; however, the sender is where the action happens, and so it's the sender that should have that (ideally, all of that) information. The less you feed back to the sender, the more prone you are to effects from dropped feedback messages (congestion on the back-path, or e.g. wireless noise). Besides, doing that stuff on the receiver side lets you ignore the fact that you may have just the right amount of ACKs with just the right type of information about your path in SCTP too, and possibly send back MORE feedback than you'd need to. So if that would be receiver-side logic within SCTP, taking care of controlling the amount of feedback to send, what would be the best way to do it? Not via some RTCP limiting rule (which doesn't really apply to underlying transports anyway, I think, i.e. you can send RTP over TCP and then it only applies to RTCP messages but not TCP ACKs, right?), but via a mechanism that is designed to send as little feedback as possible by sending just as much as is needed. For TCP, RFC 5690 described that. For some new congestion control mechanism, we'd want to have a similar scheme I suppose. If at all needed...
So my proposal would be:
- use SCTP for everything - add per-stream congestion control to it, all on the sender side - use some other RTCWeb based signalling to negotiate the congestion control mechanism, in the style of DCCP - 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...)
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:
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?
In that exact algorithm that you have specified, what you say is probably correct, and it probably wouldn't matter. But then we'd have to be careful with making any changes to that algorithm... to make sure that no policies whatsoever are incorporated in the receiver-side logic, or else the sender would have to signal the priorities to the receiver... that's just a bit messy.
... *in a unicast setting*. Multicast may be a valid point in favor of your design... do you plan for multicasting?
Cheers, Michael
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
-- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ----------------------------------------------------------------------