About the all-SCTP way of doing it
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. 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: Michael Welzl, Florian Niederbacher, Stein Gjessing: "Beneficial Transparent Deployment of SCTP: the Missing Pieces", IEEE GlobeCom 2011, 5-9 December 2011, Houston, Texas (fig.7) ...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. 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. What do y'all think? Cheers, Michael
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.
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?
Michael Welzl, Florian Niederbacher, Stein Gjessing: "Beneficial Transparent Deployment of SCTP: the Missing Pieces", IEEE GlobeCom 2011, 5-9 December 2011, Houston, Texas (fig.7)
...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.
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.
What do y'all think?
Cheers, Michael
______________________________**_________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/**mailman/listinfo/rtp-**congestion<http://www.alvestrand.no/mailman/listinfo/rtp-congestion>
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
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 ----------------------------------------------------------------------
To emphasize what Magnus said, there is a paper titled: "The delay-friendliness of TCP" which describes the operating region in which TCP may be used for VoIP (it uses RTT, loss rate, timeliness as metrics). http://dl.acm.org/citation.cfm?id=1375464 On Wed, Apr 4, 2012 at 11:10, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:
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 ----------------------------------------------------------------------
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
Folks, I apologize if I haven't been clear enough. I know all that, and I have read that paper too. But: I am not at all advocating the use of standard TCP or SCTP *congestion control*. So what I am considering here is a changed SCTP, with a different (new) congestion control mechanism, to make use of SCTP for its stream concept, ACKs, partial reliability and whatnot. Perhaps most importantly, to use its ability to have a unified view of the streams - a common piece of code that makes it easier to manipulate fairness between streams (e.g. in case that only one type of congestion control is used (see my upcoming separate email about that)), as that just becomes a scheduling function... already existing in SCTP! and to have a unified view of ACKs, making it possible to let ACKs from stream 1 benefit stream 2. Note: I added one extra comment in line below, in Magnus' email. Cheers, Michael On Apr 4, 2012, at 11:11 AM, Varun Singh wrote:
To emphasize what Magnus said, there is a paper titled: "The delay-friendliness of TCP" which describes the operating region in which TCP may be used for VoIP (it uses RTT, loss rate, timeliness as metrics).
http://dl.acm.org/citation.cfm?id=1375464
On Wed, Apr 4, 2012 at 11:10, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:
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.
I very much agree, and would see this as another point in favor of very careful receiver-side limiting of ACKs, maybe favoring sender- side control too (I now think that the main argument pro or con receiver-side control would really have to be multicast... if we want to support MANY receivers (do we? I don't know enough about RTCWeb here), receiver-side control might be the better way; but that doesn't change my argument about using SCTP).
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 ----------------------------------------------------------------------
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
participants (4)
-
Magnus Westerlund -
Michael Welzl -
Stefan Holmer -
Varun Singh