General thoughts about the congestion control for RTC web
I assembled the following text for possible inclusion in an introduction or problem statement: ---- The RTC web congestion control is distinctly different from other congestion control problems. The goal is to choose a codec and/or codec parameters that simultaneously minimize self inflicted queueing delay while maximizing [multi-media image/signal] quality. In almost all cases the selected network operating point will be well below the operating point that would be chosen by any traditional throughput maximizing congestion control algorithm. The traditional congestion control problem is to maximize throughput for some "TCP-friendly" capacity allocation, and typically involves creating standing queues at bottlenecks. Without AQM, TCP and other throughput maximizing protocols generally control against queue full. Even with AQM or delay sensing congestion control algorithms, these protocols generally strive to establish at least a small standing queue, because they get their self clock from queued data passing through the bottleneck, and the standing queue helps to smooth jitter in the ACKs and other phenomena that might otherwise cause idle (wasted) link capacity. The RTC web congestion control is explicitly designed to detect if a given encoding causes persistent queues, and to select a lower rate if so. This is nearly guaranteed to leave some unused network capacity and would be considered suboptimal for a throughput maximizing protocol. Thus it is unlikely that any properly functioning RTC web application will endanger any throughput maximizing protocol. The inverse is not at all true. It can be anticipated that TCP and other throughput maximizing protocols have the potential to cause unacceptable queueing delays for RTC web based application, unless one of two strategies are implemented: the traffic is segregated into separate queues such that delay sensitive traffic does not get queued behind throughput maximizing traffic, or alternatively that the AQM is tuned to maintain very short queues under all conditions. This latter strategy is likely to imply that the AQM creates sufficient losses or ECN marks where the throughput maximizing protocols can't fill the link, and leaves idle capacity. We assume that the RTC web traffic is somehow protected from other throughput maximizing traffic. Enabling RTC web and throughput maximizing protocols to simultaneously meet their respective objectives in a single queue is beyond the scope of this work. --- Comments? Debate? Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay
Hi, On Apr 5, 2012, at 8:12 PM, Matt Mathis wrote:
I assembled the following text for possible inclusion in an introduction or problem statement: ---- The RTC web congestion control is distinctly different from other congestion control problems. The goal is to choose a codec and/or codec parameters that simultaneously minimize self inflicted queueing delay while maximizing [multi-media image/signal] quality. In almost all cases the selected network operating point will be well below the operating point that would be chosen by any traditional throughput maximizing congestion control algorithm.
The traditional congestion control problem is to maximize throughput for some "TCP-friendly" capacity allocation, and typically involves creating standing queues at bottlenecks. Without AQM, TCP and other throughput maximizing protocols generally control against queue full. Even with AQM or delay sensing congestion control algorithms, these protocols generally strive to establish at least a small standing queue, because they get their self clock from queued data passing through the bottleneck, and the standing queue helps to smooth jitter in the ACKs and other phenomena that might otherwise cause idle (wasted) link capacity.
The RTC web congestion control is explicitly designed to detect if a given encoding causes persistent queues, and to select a lower rate if so. This is nearly guaranteed to leave some unused network capacity and would be considered suboptimal for a throughput maximizing protocol. Thus it is unlikely that any properly functioning RTC web application will endanger any throughput maximizing protocol.
The inverse is not at all true. It can be anticipated that TCP and other throughput maximizing protocols have the potential to cause unacceptable queueing delays for RTC web based application, unless one of two strategies are implemented: the traffic is segregated into separate queues such that delay sensitive traffic does not get queued behind throughput maximizing traffic, or alternatively that the AQM is tuned to maintain very short queues under all conditions. This latter strategy is likely to imply that the AQM creates sufficient losses or ECN marks where the throughput maximizing protocols can't fill the link, and leaves idle capacity.
Up to here, I like this - but it doesn't mention the need for a throughput-maximizing delay sensing congestion control mechanism for "data traffic", e.g. for sending files and such. In the light of my previous email ("one congestion control to bind them all"), this calls for at least two different types of congestion control, I guess. One would have made things easier, but I see the need for at least two based on what you've written.
We assume that the RTC web traffic is somehow protected from other throughput maximizing traffic. Enabling RTC web and throughput maximizing protocols to simultaneously meet their respective objectives in a single queue is beyond the scope of this work. --- Comments? Debate?
I would remove that last paragraph. I don't think we make any such environmental assumptions? Cheers, Michael
On Thu, Apr 5, 2012 at 11:20 AM, Michael Welzl <michawe@ifi.uio.no> wrote:
On Apr 5, 2012, at 8:12 PM, Matt Mathis wrote:
(snip)
It can be anticipated that TCP and other throughput maximizing protocols have the potential to cause unacceptable queueing delays for RTC web based application, unless one of two strategies are implemented: the traffic is segregated into separate queues such that delay sensitive traffic does not get queued behind throughput maximizing traffic, or alternatively that the AQM is tuned to maintain very short queues under all conditions. This latter strategy is likely to imply that the AQM creates sufficient losses or ECN marks where the throughput maximizing protocols can't fill the link, and leaves idle capacity.
Up to here, I like this - but it doesn't mention the need for a throughput-maximizing delay sensing congestion control mechanism for "data traffic", e.g. for sending files and such. We have several already: TCP and SCTP come to mind. Your suggestion of reinventing all of congestion control inside of RTC web, and moving all existing applications over to it is perhaps excessively ambitious and out of scope.
It has be known for a long time that throughput-maximizing delay sensing congestion control has sharing and stability problems. Don't assume that since RTC web adds additional constraints, that it makes the problem any easier.
In the light of my previous email ("one congestion control to bind them all"), this calls for at least two different types of congestion control, I guess. One would have made things easier, but I see the need for at least two based on what you've written. I agree, at least two, of which RTC web is only one. Trying to do throughput optimization inside of RTC web is doomed to either be suboptimal or at crossed purposes.
We assume that the RTC web traffic is somehow protected from other throughput maximizing traffic. Enabling RTC web and throughput maximizing protocols to simultaneously meet their respective objectives in a single queue is beyond the scope of this work.
I would remove that last paragraph. Well, what I wanted to say was to require QoS, but that is actually significantly over constrained and out of scope for the WG. For example with a simple SFQ controller, the RTCweb flow can find the rate just below the onset of persistent queuing, while the bulk data flows can find the window at the onset of loss, and both streams can meet their own criteria for optimal.
I don't think we make any such environmental assumptions?
The real point is that RTC web can not by itself prevent TCP from causing queues at a shared bottleneck, which is explicitly TCP's goal. We can not fix this aspect of the problem from within the scope of RTC web. The best we can do is specify what assumptions we are making about what the network should be doing to RTC traffic, and to create the case externally to revisit QoS and the like across the broader Internet. For the common home use case, user education is a sufficient workaround: e.g. go easy on bulk application while trying to VC. For the enterprise case, the QoS part is easy (already done?). Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay
On Apr 5, 2012, at 10:49 PM, Matt Mathis wrote:
On Thu, Apr 5, 2012 at 11:20 AM, Michael Welzl <michawe@ifi.uio.no> wrote:
On Apr 5, 2012, at 8:12 PM, Matt Mathis wrote:
(snip)
It can be anticipated that TCP and other throughput maximizing protocols have the potential to cause unacceptable queueing delays for RTC web based application, unless one of two strategies are implemented: the traffic is segregated into separate queues such that delay sensitive traffic does not get queued behind throughput maximizing traffic, or alternatively that the AQM is tuned to maintain very short queues under all conditions. This latter strategy is likely to imply that the AQM creates sufficient losses or ECN marks where the throughput maximizing protocols can't fill the link, and leaves idle capacity.
Up to here, I like this - but it doesn't mention the need for a throughput-maximizing delay sensing congestion control mechanism for "data traffic", e.g. for sending files and such. We have several already: TCP and SCTP come to mind. Your suggestion of reinventing all of congestion control inside of RTC web, and moving all existing applications over to it is perhaps excessively ambitious and out of scope.
This sounds like a misunderstanding? Or maybe it's me misunderstanding RTCWEB... see below:
It has be known for a long time that throughput-maximizing delay sensing congestion control has sharing and stability problems. Don't assume that since RTC web adds additional constraints, that it makes the problem any easier.
My point is: if a user owns the bottleneck (typicall her/his access link) and doesn't use anything else but RTCWEB, we shouldn't make that user increase her/his own delay experienced by using e.g. RTCWEB's own file transfer service within the browser. That just seems stupid to me, as it can in fact be avoided by using a delay-sensitive control.
In the light of my previous email ("one congestion control to bind them all"), this calls for at least two different types of congestion control, I guess. One would have made things easier, but I see the need for at least two based on what you've written. I agree, at least two, of which RTC web is only one. Trying to do throughput optimization inside of RTC web is doomed to either be suboptimal or at crossed purposes.
But minimal delay is an overaching goal, and creating a non-delay- sensitive traffic from within RTCWEB is therefore detrimental, I'd say. Why wouldn't it be better to mix 1) the step-wise delay-sensitive multimedia traffic with 2) delay-sensitive greedy traffic?
We assume that the RTC web traffic is somehow protected from other throughput maximizing traffic. Enabling RTC web and throughput maximizing protocols to simultaneously meet their respective objectives in a single queue is beyond the scope of this work.
I would remove that last paragraph. Well, what I wanted to say was to require QoS, but that is actually significantly over constrained and out of scope for the WG. For example with a simple SFQ controller, the RTCweb flow can find the rate just below the onset of persistent queuing, while the bulk data flows can find the window at the onset of loss, and both streams can meet their own criteria for optimal.
I don't think we make any such environmental assumptions?
The real point is that RTC web can not by itself prevent TCP from causing queues at a shared bottleneck, which is explicitly TCP's goal. We can not fix this aspect of the problem from within the scope of RTC web. The best we can do is specify what assumptions we are making about what the network should be doing to RTC traffic, and to create the case externally to revisit QoS and the like across the broader Internet.
I see that, but I still think that saying that "we assume that the RTC web traffic is somehow protected" is misleading because, in reality, we just don't. Rather, we decide to accept that TCP will be there too, and considerations about the impact that this will have on RTC web and vice versa should be in scope (even if being strictly TCP-friendly may not be the goal). All in all, I think you said all these things quite well in your text above that paragraph already, and I think that paragraph therefore doesn't add any real value. It can be a source for confusion, though.
For the common home use case, user education is a sufficient workaround: e.g. go easy on bulk application while trying to VC. For the enterprise case, the QoS part is easy (already done?).
Yes, but I don't think that this gets any more clear or obvious with that extra paragraph. Anyway, I don't have a strong opinion about this paragraph. Cheers, Michael
On 4/5/2012 2:12 PM, Matt Mathis wrote:
I assembled the following text for possible inclusion in an introduction or problem statement: ---- The RTC web congestion control is distinctly different from other congestion control problems. The goal is to choose a codec and/or codec parameters that simultaneously minimize self inflicted queueing delay while maximizing [multi-media image/signal] quality. In almost all cases the selected network operating point will be well below the operating point that would be chosen by any traditional throughput maximizing congestion control algorithm.
I'm not sure this statement is true; in an fairly unloaded network where the bottleneck is a transport link without ongoing TCP flows, the algorithms *should* largely saturate the link at the same throughput that TCP/etc would achieve (but with much lower delay/queue-lengths at the bottleneck). This is NOT an uncommon situation. Typically you'll have occasional short-lived bursts of TCP flows (short-lived flows, or short-lived traffic on a long-life flow such as is used in Gmail, etc) competing for bandwidth.
The RTC web congestion control is explicitly designed to detect if a given encoding causes persistent queues, and to select a lower rate if so. This is nearly guaranteed to leave some unused network capacity and would be considered suboptimal for a throughput maximizing protocol. Thus it is unlikely that any properly functioning RTC web application will endanger any throughput maximizing protocol.
Agreed (when the bottleneck is caused by competing flows (cross or otherwise). See my comments in an earlier message about how in most cases a delay-sensing CC algorithm should back off before TCP even sees losses - though not in all cases. In any steady-state case, however, which is what you're referring to here, the delay-sensing CC is likely to either end up pinned to the floor (adapt down to min or quit), or be forced to convert into loss-based, high delay mode.
The inverse is not at all true. It can be anticipated that TCP and other throughput maximizing protocols have the potential to cause unacceptable queueing delays for RTC web based application, unless one of two strategies are implemented: the traffic is segregated into separate queues such that delay sensitive traffic does not get queued behind throughput maximizing traffic, or alternatively that the AQM is tuned to maintain very short queues under all conditions.
I'm not certain this is the case; I can imagine algorithms that attempt to avoid being pinned to the floor by at least occasionally delaying reduction in bandwidth and accepting a short burst of delay in order to force TCP flows to back off (for a while). This may result in an unacceptable user experience, however, especially if the queue depth is long (some bufferbloat examples can result in 1/2-1s or longer delays before loss will be seen). I'm not certain that such algorithms could actually succeed, however, even with the periodic negative impacts. It *might* be effective in managing problems cause by bursts of competing short-term TCP flows (typically browser HTTP page-load behavior, for example).
We assume that the RTC web traffic is somehow protected from other throughput maximizing traffic. Enabling RTC web and throughput maximizing protocols to simultaneously meet their respective objectives in a single queue is beyond the scope of this work.
I'd state more that it's understood that long-term competing TCP flows (of sufficient potential bandwidth in total) will either out-compete the rtcweb traffic or force it into a loss-based, high-delay behavior, which may or may not be acceptable to the user, depending on the induced queuing delay in the bottleneck node/connection. -- Randell Jesup randell-ietf@jesup.org
participants (3)
-
Matt Mathis -
Michael Welzl -
Randell Jesup