On 4/7/2012 1:37 PM, Michael Welzl wrote:
On Apr 7, 2012, at 7:19 PM, Randell Jesup wrote:
What's the RTO in this case, since we're talking UDP media streams? TCP RTO?
Something in the order of that is what I had in mind. An RTT is the control interval that we can and should act upon, and of course you'd rather have an estimate that is averaged, and you really want to avoid having false positives from outliers, so you want to give it a reasonable safety margin. The TCP RTO has all that.
Note I'm not "religious" about this - I think a mechanism that would react e.g. an RTT late could still lead to a globally "okay" behavior (but that would then be worth a closer investigation). My main point is that it should be around an RTO, or maybe a bit more, but not completely detached from RTT measurements.
One thing I worry about for media streams if you mandate RTT-timeframe reaction (which usually means RTT-timeframe distance between reverse-path reporting) is the amount of potential additional reverse-path traffic they can engender. This is especially relevant in UDP land you don't have ACKs, and the available additional path of RTCP is bandwidth-limited itself with rules that might not allow you to send immediately. This could be an especially relevant constraint on low-RTT channels, especially if they're also low-bandwidth. IIRC, the same issue/impact was flagged in TFRC, but I think the issue may be worse here. In terms of global stability, an aspect of these sorts of algorithms that helps is that even if they may be a little slow to react(*) in a downward direction, they are also typically slow to re-take bandwidth. If they also use the slope of the delay change to estimate bandwidth, they can also be more accurate in their reaction to bandwidth availability changes, so when they do react they tend to avoid undershooting, and don't overshoot by much the way TCP may. (*) It's important to note that in normal operation, a delay-sensing algorithm may react much *faster* than TCP even if the reaction delay is many RTT - because the clock starts counting for a delay-sensitive algorithm when the bottleneck appears, not when the buffer overflows at the bottleneck. A delay sensitive algorithm that isn't faced with giant changes in queue depth will almost always react faster than TCP IMHO. The remaining question is what happens when the bottleneck faces a massive sudden cross-flow that suddenly saturates the buffer. As mentioned, if slope is used the delay-sensing algorithm may well cut bandwidth faster than TCP would, even if it reacts a little later in this case; doubly-so if the algorithm includes losses as an indication that not only has delay increased at the slope rate, but that on top of that a buffer has overflowed, and so losses should cause it to increase the estimate of the bandwidth change. -- Randell Jesup randell-ietf@jesup.org