Re: [R-C] Congestion Control BOF
Randell, This is a good start, indeed! Some comments on the details of your initial email are below. About simulation: Does anyone have any suggestions for suitable simulation tools? ns2 is one choice of course, but I'm not very pleased with it. /Henrik & Stefan @ Google On Sat, Oct 8, 2011 at 12:38 AM, Randell Jesup <randell@jesup.org> wrote:
This email is being sent to everyone who expressed an interest in a congestion-control BOF group or who responded to the previous thread on the subject. Feel free to ignore it or ask to be dropped if you're not interested.
If people feel we should, I'm happy to take this back to the main rtcweb list.
So, per my posting on congestion control, I'm advocating combining all the media streams into one congestion control domain, and modifying the Google/GIPS algorithm to take the changes this brings into account. (I have a few other suggested tweaks as well.) This goes into more detail on exactly how one would modify the algorithm.
First, some comments on the current algorithm:
1. Frames with internal packet loss should not be fed as an input to the kalman filter. Especially if the packet was lost after the bottleneck it may give a false input (if lost at/before the bottleneck it probably would be ok). In general sequences with packet loss may give suspect results; see point 4 below.
Agree. The reason we are using frames with losses in the current implementation is mainly code technicality.
2. I would use something more adaptive than the current _beta in RemoteRateControl. Currently if we're over-bandwidth, it cuts bandwidth by 5 or 10% (depending on where we are relative to the "known good max") and hopes that's below the bottleneck bandwidth. On a large change (or bad mis-estimation) the bandwidth might still be above bottleneck rate, and you *really* want to get down below it to drain the buffers fast.
I would prefer to use the effective incoming "slope" (which the magnitude of the Kalman filter should tell us) to estimate how far over-bandwidth we are. If we're receiving 500Kbps, and 33ms frames are coming in at an average of 36ms, the bandwidth estimate would be ~458Kbps, so to be safe and allow those buffers to drain, I'd probably want to target something like 430Kbps until they drain. If they came in at 45ms, which implies ~366Kbps available, I'd drop to somewhere around 300 at a guess - dropping to 430 would cause delay to continue to increase. Also, if there's loss I feel you should drop the rate more, since the bottleneck router (if it has short queues) may have started to tail-drop - and if it random-drops, your estimate may be too high.
I do not agree with you here. When an over-use is detected, we propose to measure the *actual* throughput (over the last 1 second), and set the target bitrate to beta times this throughput. Since the measured throughput is a rate that evidently was feasible (at least during that 1 second), any beta < 1 should assert that the buffers get drained, but of course at different rates depending on the magnitude of beta. 3. Similarly, I'd want to allow for a smaller 'beta' (faster cuts, alpha for
faster increases) at the start of a call. It's unclear to me from the code if that's the case currently, though if it is it's a side-effect of other things like the rcRegion and the maxHoldRate.
I'm not sure I fully understand what you mean by "faster cuts", but I gather that you're aiming at speeding up the convergence (up or down) during the startup phase. In general, we do agree that it's a good idea to let the algorithm be more agile in the beginning. Regarding the beta value, see my comment to #2 above.
Overall, the general approach in RateIncreaseFactor for alpha and the code that calls it is good and matches my understanding of reasonable approaches. I might also want to slow the rate of increase (especially over the max rate where we didn't see delay increase) every time we get knocked back, which allows for a fast converging search for the channel bandwidth, again especially at the start of a call, though this could be in play after any significant change.
This was already implemented in the algorithm, although not described in the document.
4. If a drop occurs at or before the bottleneck, you'll get an unusually-short arrival delta compared to the Ts delta. I would consider such drops "fishy" as they may indicate tail-dropping somewhere in the chain, and if we see "too many" of them drop bandwidth by a larger amount, even if the Kalman filter indicates Hold.
This would be especially important if the bottleneck has a (very) short queue - it may build up, drop, build up, drop, etc and to the Kalman filter it might look like you weren't over-bandwidth, just a lot of jitter.
This is probably an important corner case (maybe not even a corner...). We would have to come up with some extended loss processing at the receiver. It's probably necessary to come test this in a simulation environment were the bottleneck queues can be varied at will.
5. It appears that the code in remote_rate_control.cc (i.e.receiver) currently starts at the max-configured bitrate; is this correct? What's the impact of this; what does the sender-side start at?
This is correct, and means that the receiver side does not enforce or ask for any rate reduction until it has experienced the first over-bandwidth.
Ok, now on to merging the media stream congestion control states.
The overall idea is that all the packets from all media streams are fed into the same 'bin' as if they were parts of the same source. There are two primary ways to do this:
1) calculate the delta for each stream separately (produce CompensatedTimeDelta(), which is in ms), and feed into a single Kalman filter
2) calculate the delta as if all the packets are one stream, by mapping the timestamps of the separate streams to one drift-compensated NTP time base, then produce CompensatedTimeDelta() and feed to Kalman.
(see http://code.google.com/p/webrtc/source/browse/trunk/src/modules/rtp_rtcp/sou... )
#2 (probably) needs drift compensation since we can't guarantee that the timestamps of different streams are sourced from the same clock. It's possible that for "normal" drifts this wouldn't be an issue, but I'm leary since I've seen some PBXes and devices that have significant drift (though in this case we only really care about differential drift).
Note that currently the UpdateKalman() function has the drift compensation inside of it; for either of these it would need to move out of UpdateKalman().
If you follow the code, you'll see that the CurrentDrift() method is a dummy always returning 1.0. TBD :)
A primary change needed (in both of these) is that the current Kalman filter is based around an assumption of 30fps source rate. From page 6 of Harald's draft:
The variance var_v = sigma(v,i)^2 is estimated using an exponential averaging filter, modified for variable sampling rate
var_v_hat = beta*sigma(v,i-1)^2 + (1-beta)*z(i)^2
beta = (1-alpha)30/(1000 * f_max)
where f_max = max {1/(T(j) - T(j-1))} for j in i-K+1...i is the highest rate at which frames have been captured by the camera the last K frames and alpha is a filter coefficient typically chosen as a number in the interval [0.1, 0.001]. Since our assumption that v(i) should be zero mean WGN is less accurate in some cases, we have introduced an additional outlier filter around the updates of var_v_hat. If z(i) > 3 var_v_hat the filter is updated with 3 sqrt(var_v_hat) rather than z(i). In a similar way, Q(i) is chosen as a diagonal matrix with main diagonal elements given by
diag(Q(i)) = 30/(1000 * f_max)[10^-10 10^-2]^T
It is necessary to scale these filter parameters with the frame rate to make the detector respond as quickly at low frame rates as at high frame rates.
This assumes that the frame rate == 1/shortest_ts_diff, which is a slightly loose assumption, even without merging streams - though I agree most encoders encode at a fairly fixed rate, and 30 is the most common. But it still could be well off especially at transition points (say from still to moving) - the encoder might run at 30fps (or more) when still, and drop to 5 or 10 fps (or lower) when the scene transitions into high motion.
I'll also note that the noise estimate is also based on a 30fps assumption, though that might be easier to modify. The noise estimate slews more quickly for the first ~ 10 seconds.
The 30 fps that you see in the equations is because the tuning of the design parameters was done for a nominal 30 fps. But the formulae are actually there to compensate the parameters such that the system should work for other frame rates too. It looks hard-coded, but it's not. You could argue that using the max frame rate (over some window) is not correct. We tried with mean frame rate at one stage, but had some problems with bias. Probably we just didn't gather enough facts and understanding to resolve the issue properly.
I'm not familiar enough with Kalman filters to *know* if it would be best to change the scale factor to be based on the recent actual frame rate (instead of recent max frame rate); I suspect it's better but not "right".
From checking on the theory of Kalman filters, there's no inherent reason that it can't take inputs at different timestamp deltas - for that matter, with some adjustments, it should be possible to use every packet as an input to the filter, not just the last packet of a frame. I'm not sure if in practice this would improve the output or not, but it might be worth trying.
So, without going into line-by-line changes, my suggestion is to remove the reliance on 30fps; to use an average observed frame rate instead of the max recent frame rate, and we should feed all the inputs into one kalman filter (perhaps trying both variants above), and see how it works in practice and simulation.
I'll note that my practice I've found that you don't need a very good filter to identify over-bandwidth situations; even a simple averaging filter run over a second or so can usually pick up on bottleneck buffer states pretty accurately. A Kalman filter certainly should be better than that and provide faster response, but my point is that it doesn't have to be perfect to work.
BTW - there's lots of code in there to generate matlab output, to run it standalone (though that seems turned off), etc. Any guidance or pointers to docs on how to build and run these tests, and how to get these stats out of running calls? I'm sure I can root around and figure it out, but a pointer would save a bunch of time. Thanks!
Once upon a time, we used this code for real-time visualization of the bandwidth estimator using a Matlab Engine. It worked well on Windows with the ancient Matlab 5 or 6, or so. We're currently working in a linux environment with the latest and greatest Matlab release, and now the real-time plotting is quite far from real-time. There is unfortunately no docs that describes what's going on. I can see what old code I can dig out.
Thanks! I think we can help make something here that will really raise the bar.
Randell Jesup (sent from my private email address)
FYI - if anyone is getting this and hasn't joined the R-C (congestion control) list, please do so as I'm going to stop CC-ing individuals at some point today. On 10/11/2011 3:11 AM, Henrik Lundin wrote:
Randell,
This is a good start, indeed! Some comments on the details of your initial email are below.
Thanks!
About simulation: Does anyone have any suggestions for suitable simulation tools? ns2 is one choice of course, but I'm not very pleased with it.
I don't have strong opinions; I've used both dummynet (for simple testing, though the latest ones are better for simulating variable delay and loss), and NetEm, which I'm not an expert with, but at least provides normal distributions of delay, correlation of delays/loss, etc. You'd need to use it with a rate control discipline to model a router/NAT/modem. For modern uses of dummynet in PlantLab, etc see http://info.iet.unipi.it/~luigi/dummynet/ and http://info.iet.unipi.it/~luigi/papers/20100316-cc-preprint.pdf More comments in-line...
2. I would use something more adaptive than the current _beta in RemoteRateControl. Currently if we're over-bandwidth, it cuts bandwidth by 5 or 10% (depending on where we are relative to the "known good max") and hopes that's below the bottleneck bandwidth. On a large change (or bad mis-estimation) the bandwidth might still be above bottleneck rate, and you *really* want to get down below it to drain the buffers fast.
I would prefer to use the effective incoming "slope" (which the magnitude of the Kalman filter should tell us) to estimate how far over-bandwidth we are. If we're receiving 500Kbps, and 33ms frames are coming in at an average of 36ms, the bandwidth estimate would be ~458Kbps, so to be safe and allow those buffers to drain, I'd probably want to target something like 430Kbps until they drain. If they came in at 45ms, which implies ~366Kbps available, I'd drop to somewhere around 300 at a guess - dropping to 430 would cause delay to continue to increase. Also, if there's loss I feel you should drop the rate more, since the bottleneck router (if it has short queues) may have started to tail-drop - and if it random-drops, your estimate may be too high.
I do not agree with you here. When an over-use is detected, we propose to measure the /actual/ throughput (over the last 1 second), and set the target bitrate to beta times this throughput. Since the measured throughput is a rate that evidently was feasible (at least during that 1 second), any beta < 1 should assert that the buffers get drained, but of course at different rates depending on the magnitude of beta.
For static analysis (detect the bandwidth of the modem, etc) I agree with you. However, for mid-call detection of changes in bandwidth and particularly cross-traffic using recent throughput as a guide will be wrong. The point is that bandwidth has changed, and if it changed by more than beta you'll still be over. Even in startup you may find recent traffic is a bad predictor (and you have less to go on), especially if you "start low" and move rapidly up-bandwidth, as suggested by myself and Magnus, instead of starting high and cutting back. (see below).
3. Similarly, I'd want to allow for a smaller 'beta' (faster cuts, alpha for faster increases) at the start of a call. It's unclear to me from the code if that's the case currently, though if it is it's a side-effect of other things like the rcRegion and the maxHoldRate.
I'm not sure I fully understand what you mean by "faster cuts", but I gather that you're aiming at speeding up the convergence (up or down) during the startup phase. In general, we do agree that it's a good idea to let the algorithm be more agile in the beginning. Regarding the beta value, see my comment to #2 above.
"faster cuts" means faster reduction in bandwidth; so yes I'm referring to running faster convergence in startup. It also may be smart to return to this region on interface changes (definitely) and on major cross-traffic changes (which often are a spike of web-page-loading, not a long-term flow).
Overall, the general approach in RateIncreaseFactor for alpha and the code that calls it is good and matches my understanding of reasonable approaches. I might also want to slow the rate of increase (especially over the max rate where we didn't see delay increase) every time we get knocked back, which allows for a fast converging search for the channel bandwidth, again especially at the start of a call, though this could be in play after any significant change.
This was already implemented in the algorithm, although not described in the document.
Good. I didn't see anything that directly looked at how recently/often we'd had to reduce bitrate.
4. If a drop occurs at or before the bottleneck, you'll get an unusually-short arrival delta compared to the Ts delta. I would consider such drops "fishy" as they may indicate tail-dropping somewhere in the chain, and if we see "too many" of them drop bandwidth by a larger amount, even if the Kalman filter indicates Hold.
This would be especially important if the bottleneck has a (very) short queue - it may build up, drop, build up, drop, etc and to the Kalman filter it might look like you weren't over-bandwidth, just a lot of jitter.
This is probably an important corner case (maybe not even a corner...). We would have to come up with some extended loss processing at the receiver. It's probably necessary to come test this in a simulation environment were the bottleneck queues can be varied at will.
This is important in my experience - not every device implements bufferbloat. ;-) I also believe that there are router/bottleneck configurations that will cause earlier bottleneck signals to be "lost" later on due to router packet scheduling and cross traffic. This is accentuated by the common bottleneck being the local upstream link, so you have many routers and cross-traffic following it.
5. It appears that the code in remote_rate_control.cc (i.e.receiver) currently starts at the max-configured bitrate; is this correct? What's the impact of this; what does the sender-side start at?
This is correct, and means that the receiver side does not enforce or ask for any rate reduction until it has experienced the first over-bandwidth.
Ok, as per above and Magnus's comments, I tend to disagree with this - it almost guarantees you'll be in recovery right at the start of the call, which is not the best experience for 1-to-1 communication, IMHO (and in my experience). See my extensive discussion of starting bandwidths on rtcweb (I should copy it here for archival).
#2 (probably) needs drift compensation since we can't guarantee that the timestamps of different streams are sourced from the same clock. It's possible that for "normal" drifts this wouldn't be an issue, but I'm leary since I've seen some PBXes and devices that have significant drift (though in this case we only really care about differential drift).
Note that currently the UpdateKalman() function has the drift compensation inside of it; for either of these it would need to move out of UpdateKalman().
If you follow the code, you'll see that the CurrentDrift() method is a dummy always returning 1.0. TBD :)
Hmmm. Oh well. I guarantee there are devices out there that drift a lot... And even have time go backwards (great fun there).
A primary change needed (in both of these) is that the current Kalman filter is based around an assumption of 30fps source rate. From page 6 of Harald's draft:
The variance var_v = sigma(v,i)^2 is estimated using an exponential averaging filter, modified for variable sampling rate
var_v_hat = beta*sigma(v,i-1)^2 + (1-beta)*z(i)^2
beta = (1-alpha)30/(1000 * f_max)
where f_max = max {1/(T(j) - T(j-1))} for j in i-K+1...i is the highest rate at which frames have been captured by the camera the last K frames and alpha is a filter coefficient typically chosen as a number in the interval [0.1, 0.001]. Since our assumption that v(i) should be zero mean WGN is less accurate in some cases, we have introduced an additional outlier filter around the updates of var_v_hat. If z(i) > 3 var_v_hat the filter is updated with 3 sqrt(var_v_hat) rather than z(i). In a similar way, Q(i) is chosen as a diagonal matrix with main diagonal elements given by
diag(Q(i)) = 30/(1000 * f_max)[10^-10 10^-2]^T
It is necessary to scale these filter parameters with the frame rate to make the detector respond as quickly at low frame rates as at high frame rates.
This assumes that the frame rate == 1/shortest_ts_diff, which is a slightly loose assumption, even without merging streams - though I agree most encoders encode at a fairly fixed rate, and 30 is the most common. But it still could be well off especially at transition points (say from still to moving) - the encoder might run at 30fps (or more) when still, and drop to 5 or 10 fps (or lower) when the scene transitions into high motion.
I'll also note that the noise estimate is also based on a 30fps assumption, though that might be easier to modify. The noise estimate slews more quickly for the first ~ 10 seconds.
The 30 fps that you see in the equations is because the tuning of the design parameters was done for a nominal 30 fps. But the formulae are actually there to compensate the parameters such that the system should work for other frame rates too. It looks hard-coded, but it's not.
Ok, I'll look to the code, though I thought I saw the same hard-coded assumptions.
You could argue that using the max frame rate (over some window) is not correct. We tried with mean frame rate at one stage, but had some problems with bias. Probably we just didn't gather enough facts and understanding to resolve the issue properly.
A simple weighted moving average of some sort is probably good enough. Otherwise detection right after a sudden drop in frame rate could be compromised (and sudden drops in frame rate may also correlate with increases in bandwidth usage, depending on the encoder).
BTW - there's lots of code in there to generate matlab output, to run it standalone (though that seems turned off), etc. Any guidance or pointers to docs on how to build and run these tests, and how to get these stats out of running calls? I'm sure I can root around and figure it out, but a pointer would save a bunch of time. Thanks!
Once upon a time, we used this code for real-time visualization of the bandwidth estimator using a Matlab Engine. It worked well on Windows with the ancient Matlab 5 or 6, or so. We're currently working in a linux environment with the latest and greatest Matlab release, and now the real-time plotting is quite far from real-time. There is unfortunately no docs that describes what's going on. I can see what old code I can dig out.
Well, I don't own Matlab, so it won't help me anyways. And if it's just for plotting, there have to be some simpler ways to do real-time data plotting on Linux (or others). -- Randell Jesup randell-ietf@jesup.org
On Tue, Oct 11, 2011 at 5:17 PM, Randell Jesup <randell-ietf@jesup.org>wrote:
FYI - if anyone is getting this and hasn't joined the R-C (congestion control) list, please do so as I'm going to stop CC-ing individuals at some point today.
On 10/11/2011 3:11 AM, Henrik Lundin wrote:
Randell,
This is a good start, indeed! Some comments on the details of your initial email are below.
Thanks!
About simulation: Does anyone have any suggestions for suitable
simulation tools? ns2 is one choice of course, but I'm not very pleased with it.
I don't have strong opinions; I've used both dummynet (for simple testing, though the latest ones are better for simulating variable delay and loss), and NetEm, which I'm not an expert with, but at least provides normal distributions of delay, correlation of delays/loss, etc. You'd need to use it with a rate control discipline to model a router/NAT/modem.
For modern uses of dummynet in PlantLab, etc see http://info.iet.unipi.it/~**luigi/dummynet/<http://info.iet.unipi.it/~luigi/dummynet/> and http://info.iet.unipi.it/~**luigi/papers/20100316-cc-**preprint.pdf<http://info.iet.unipi.it/~luigi/papers/20100316-cc-preprint.pdf>
More comments in-line...
I was primarily looking for offline simulation tools. NetEm and dummynet are both tools for emulating network impairments to real-time traffic, right?
2. I would use something more adaptive than the current _beta in
RemoteRateControl. Currently if we're over-bandwidth, it cuts bandwidth by 5 or 10% (depending on where we are relative to the "known good max") and hopes that's below the bottleneck bandwidth. On a large change (or bad mis-estimation) the bandwidth might still be above bottleneck rate, and you *really* want to get down below it to drain the buffers fast.
I would prefer to use the effective incoming "slope" (which the magnitude of the Kalman filter should tell us) to estimate how far over-bandwidth we are. If we're receiving 500Kbps, and 33ms frames are coming in at an average of 36ms, the bandwidth estimate would be ~458Kbps, so to be safe and allow those buffers to drain, I'd probably want to target something like 430Kbps until they drain. If they came in at 45ms, which implies ~366Kbps available, I'd drop to somewhere around 300 at a guess - dropping to 430 would cause delay to continue to increase. Also, if there's loss I feel you should drop the rate more, since the bottleneck router (if it has short queues) may have started to tail-drop - and if it random-drops, your estimate may be too high.
I do not agree with you here. When an over-use is detected, we propose to measure the /actual/ throughput (over the last 1 second), and set the
target bitrate to beta times this throughput. Since the measured throughput is a rate that evidently was feasible (at least during that 1 second), any beta < 1 should assert that the buffers get drained, but of course at different rates depending on the magnitude of beta.
For static analysis (detect the bandwidth of the modem, etc) I agree with you. However, for mid-call detection of changes in bandwidth and particularly cross-traffic using recent throughput as a guide will be wrong. The point is that bandwidth has changed, and if it changed by more than beta you'll still be over.
Even in startup you may find recent traffic is a bad predictor (and you have less to go on), especially if you "start low" and move rapidly up-bandwidth, as suggested by myself and Magnus, instead of starting high and cutting back. (see below).
3. Similarly, I'd want to allow for a smaller 'beta' (faster cuts,
alpha for faster increases) at the start of a call. It's unclear to me from the code if that's the case currently, though if it is it's a side-effect of other things like the rcRegion and the maxHoldRate.
I'm not sure I fully understand what you mean by "faster cuts", but I gather that you're aiming at speeding up the convergence (up or down) during the startup phase. In general, we do agree that it's a good idea to let the algorithm be more agile in the beginning. Regarding the beta value, see my comment to #2 above.
"faster cuts" means faster reduction in bandwidth; so yes I'm referring to running faster convergence in startup. It also may be smart to return to this region on interface changes (definitely) and on major cross-traffic changes (which often are a spike of web-page-loading, not a long-term flow).
Overall, the general approach in RateIncreaseFactor for alpha and
the code that calls it is good and matches my understanding of reasonable approaches. I might also want to slow the rate of increase (especially over the max rate where we didn't see delay increase) every time we get knocked back, which allows for a fast converging search for the channel bandwidth, again especially at the start of a call, though this could be in play after any significant change.
This was already implemented in the algorithm, although not described in the document.
Good. I didn't see anything that directly looked at how recently/often we'd had to reduce bitrate.
4. If a drop occurs at or before the bottleneck, you'll get an
unusually-short arrival delta compared to the Ts delta. I would consider such drops "fishy" as they may indicate tail-dropping somewhere in the chain, and if we see "too many" of them drop bandwidth by a larger amount, even if the Kalman filter indicates Hold.
This would be especially important if the bottleneck has a (very) short queue - it may build up, drop, build up, drop, etc and to the Kalman filter it might look like you weren't over-bandwidth, just a lot of jitter.
This is probably an important corner case (maybe not even a corner...). We would have to come up with some extended loss processing at the receiver. It's probably necessary to come test this in a simulation environment were the bottleneck queues can be varied at will.
This is important in my experience - not every device implements bufferbloat. ;-) I also believe that there are router/bottleneck configurations that will cause earlier bottleneck signals to be "lost" later on due to router packet scheduling and cross traffic. This is accentuated by the common bottleneck being the local upstream link, so you have many routers and cross-traffic following it.
5. It appears that the code in remote_rate_control.cc (i.e.receiver)
currently starts at the max-configured bitrate; is this correct? What's the impact of this; what does the sender-side start at?
This is correct, and means that the receiver side does not enforce or ask for any rate reduction until it has experienced the first over-bandwidth.
Ok, as per above and Magnus's comments, I tend to disagree with this - it almost guarantees you'll be in recovery right at the start of the call, which is not the best experience for 1-to-1 communication, IMHO (and in my experience). See my extensive discussion of starting bandwidths on rtcweb (I should copy it here for archival).
I think there has been a misunderstanding here. It is true that the code in the receiver-side of the CC algorithm (specifically in remote_rate_control.cc) starts at the max-configured rate. This is while waiting for it to detect the first over-use. However, and this is were the catch is, it does not mean that the sender starts sending at the max rate. In our current implementation, the sender decides the actual start rate. Further, since the original implementation was done based on TMMBR, we had to implement a stand-alone CC at the sender too, since it's not allowed to rely on TMMBR alone. Thus, as long as the TMMBR feedback is larger than what the sender's internal CC says, it will not listen to the TMMBR. Therefore, the receive-side initialization that you see does not mean that we start each call at ludicrous speed. Some of the things in the implementation are legacy...
#2 (probably) needs drift compensation since we can't guarantee that
the timestamps of different streams are sourced from the same clock. It's possible that for "normal" drifts this wouldn't be an issue, but I'm leary since I've seen some PBXes and devices that have significant drift (though in this case we only really care about differential drift).
Note that currently the UpdateKalman() function has the drift compensation inside of it; for either of these it would need to move out of UpdateKalman().
If you follow the code, you'll see that the CurrentDrift() method is a dummy always returning 1.0. TBD :)
Hmmm. Oh well. I guarantee there are devices out there that drift a lot... And even have time go backwards (great fun there).
I'm sure there are. So far we have not seen drift large enough to actually offset the over-/under-use detection.
A primary change needed (in both of these) is that the current Kalman filter is based around an assumption of 30fps source rate. From page 6 of Harald's draft:
The variance var_v = sigma(v,i)^2 is estimated using an exponential averaging filter, modified for variable sampling rate
var_v_hat = beta*sigma(v,i-1)^2 + (1-beta)*z(i)^2
beta = (1-alpha)30/(1000 * f_max)
where f_max = max {1/(T(j) - T(j-1))} for j in i-K+1...i is the highest rate at which frames have been captured by the camera the last K frames and alpha is a filter coefficient typically chosen as a number in the interval [0.1, 0.001]. Since our assumption that v(i) should be zero mean WGN is less accurate in some cases, we have introduced an additional outlier filter around the updates of var_v_hat. If z(i) > 3 var_v_hat the filter is updated with 3 sqrt(var_v_hat) rather than z(i). In a similar way, Q(i) is chosen as a diagonal matrix with main diagonal elements given by
diag(Q(i)) = 30/(1000 * f_max)[10^-10 10^-2]^T
It is necessary to scale these filter parameters with the frame rate to make the detector respond as quickly at low frame rates as at high frame rates.
This assumes that the frame rate == 1/shortest_ts_diff, which is a slightly loose assumption, even without merging streams - though I agree most encoders encode at a fairly fixed rate, and 30 is the most common. But it still could be well off especially at transition points (say from still to moving) - the encoder might run at 30fps (or more) when still, and drop to 5 or 10 fps (or lower) when the scene transitions into high motion.
I'll also note that the noise estimate is also based on a 30fps assumption, though that might be easier to modify. The noise estimate slews more quickly for the first ~ 10 seconds.
The 30 fps that you see in the equations is because the tuning of the design parameters was done for a nominal 30 fps. But the formulae are actually there to compensate the parameters such that the system should work for other frame rates too. It looks hard-coded, but it's not.
Ok, I'll look to the code, though I thought I saw the same hard-coded assumptions.
You
could argue that using the max frame rate (over some window) is not correct. We tried with mean frame rate at one stage, but had some problems with bias. Probably we just didn't gather enough facts and understanding to resolve the issue properly.
A simple weighted moving average of some sort is probably good enough. Otherwise detection right after a sudden drop in frame rate could be compromised (and sudden drops in frame rate may also correlate with increases in bandwidth usage, depending on the encoder).
BTW - there's lots of code in there to generate matlab output, to
run it standalone (though that seems turned off), etc. Any guidance or pointers to docs on how to build and run these tests, and how to get these stats out of running calls? I'm sure I can root around and figure it out, but a pointer would save a bunch of time. Thanks!
Once upon a time, we used this code for real-time visualization of the bandwidth estimator using a Matlab Engine. It worked well on Windows with the ancient Matlab 5 or 6, or so. We're currently working in a linux environment with the latest and greatest Matlab release, and now the real-time plotting is quite far from real-time. There is unfortunately no docs that describes what's going on. I can see what old code I can dig out.
Well, I don't own Matlab, so it won't help me anyways. And if it's just for plotting, there have to be some simpler ways to do real-time data plotting on Linux (or others).
-- Randell Jesup randell-ietf@jesup.org
On Wed, Oct 12, 2011 at 18:25, Henrik Lundin <henrik.lundin@webrtc.org> wrote:
On Tue, Oct 11, 2011 at 5:17 PM, Randell Jesup <randell-ietf@jesup.org> wrote:
On 10/11/2011 3:11 AM, Henrik Lundin wrote:
Randell,
This is a good start, indeed! Some comments on the details of your initial email are below.
Thanks!
About simulation: Does anyone have any suggestions for suitable simulation tools? ns2 is one choice of course, but I'm not very pleased with it.
I don't have strong opinions; I've used both dummynet (for simple testing, though the latest ones are better for simulating variable delay and loss), and NetEm, which I'm not an expert with, but at least provides normal distributions of delay, correlation of delays/loss, etc. You'd need to use it with a rate control discipline to model a router/NAT/modem.
For modern uses of dummynet in PlantLab, etc see http://info.iet.unipi.it/~luigi/dummynet/ and http://info.iet.unipi.it/~luigi/papers/20100316-cc-preprint.pdf
More comments in-line...
I was primarily looking for offline simulation tools. NetEm and dummynet are both tools for emulating network impairments to real-time traffic, right?
NetEm and Dummynet can emulate network characteristics like change in link capacity, one-way delay, bit-error rate. One can enable these characteristics on a specific source interface/ip address or port or apply it to outgoing or incoming packets. I think even to specific protocols such as just TCP or UDP. We have run simulations using ns2 but they take a lot of time because ns2 is event driven and therefore the clock is not real-time (not in sync with system clock). A 10 minute video call may take any where from 1-3 hrs or even longer to simulate depending on the scenario (number of cross traffic, type of simulation etc.). Our code is not available but some researchers use EvalVid-RA for NS2. The sources are available at http://www.item.ntnu.no/~arnelie/Evalvid-RA.htm.
On 10/12/2011 11:25 AM, Henrik Lundin wrote:
About simulation: Does anyone have any suggestions for suitable simulation tools? ns2 is one choice of course, but I'm not very pleased with it.
I don't have strong opinions; I've used both dummynet (for simple testing, though the latest ones are better for simulating variable delay and loss), and NetEm, which I'm not an expert with, but at least provides normal distributions of delay, correlation of delays/loss, etc. You'd need to use it with a rate control discipline to model a router/NAT/modem.
For modern uses of dummynet in PlantLab, etc see
PlanetLab, sorry
http://info.iet.unipi.it/~__luigi/dummynet/ <http://info.iet.unipi.it/~luigi/dummynet/> and http://info.iet.unipi.it/~__luigi/papers/20100316-cc-__preprint.pdf <http://info.iet.unipi.it/~luigi/papers/20100316-cc-preprint.pdf>
More comments in-line...
I was primarily looking for offline simulation tools. NetEm and dummynet are both tools for emulating network impairments to real-time traffic, right?
I honestly don't have a lot of love for fully offline, non-real-time simulations like ns2 for this sort of work - the realtime algorithms have often are painful to rework to run paced by the simulation, and to be honest I want a reasonable approximation of a real network, where subjective measurements and evaluation can be quickly done. Plus I find Dummynet/Netem more intuitive than what I know about using ns2 (which I've never actually used, but the comments from Varun Singh make me shudder at using it as a primary tool. My preference is for netem and/or dummynet across a bench and also for connecting a device to a corporate or high-speed residential network while simulating a much lower-speed or loaded access link. Hook up a switch or NAT and a PC to run transfers, make VoIP calls, run bittorrent(!!), randomly browse, watch Youtube, etc while making video calls on the target. We also used to have regular residential cable modems as well. Make lots of actual calls where you're talking to someone; humans are very good at picking out most types of errors - especially the ones that matter, and you can also collect statistics while doing so. Combine those tools with a few good testers and you'll find all sorts of funny edge conditions that most straight simulations miss. IMHO.
5. It appears that the code in remote_rate_control.cc (i.e.receiver) currently starts at the max-configured bitrate; is this correct? What's the impact of this; what does the sender-side start at?
This is correct, and means that the receiver side does not enforce or ask for any rate reduction until it has experienced the first over-bandwidth.
Ok, as per above and Magnus's comments, I tend to disagree with this - it almost guarantees you'll be in recovery right at the start of the call, which is not the best experience for 1-to-1 communication, IMHO (and in my experience). See my extensive discussion of starting bandwidths on rtcweb (I should copy it here for archival).
I think there has been a misunderstanding here. It is true that the code in the receiver-side of the CC algorithm (specifically in remote_rate_control.cc) starts at the max-configured rate. This is while waiting for it to detect the first over-use. However, and this is were the catch is, it does not mean that the sender starts sending at the max rate. In our current implementation, the sender decides the actual start rate. Further, since the original implementation was done based on TMMBR, we had to implement a stand-alone CC at the sender too, since it's not allowed to rely on TMMBR alone. Thus, as long as the TMMBR feedback is larger than what the sender's internal CC says, it will not listen to the TMMBR. Therefore, the receive-side initialization that you see does not mean that we start each call at ludicrous speed. Some of the things in the implementation are legacy...
Ok, good - I thought I'd asked that question when we all were chatting and I probably wasn't specific enough.
Hmmm. Oh well. I guarantee there are devices out there that drift a lot... And even have time go backwards (great fun there).
I'm sure there are. So far we have not seen drift large enough to actually offset the over-/under-use detection.
I'm told some PC audio cards/interfaces have significantly drifty timebases - but perhaps not at a level that matters here. When working with the old GIPS code, we kept a PLL tracking the apparent timebase of each far-end stream, updated on RTCP reports, and reset if something "odd" happens. -- Randell Jesup randell-ietf@jesup.org
On Wed, Oct 12, 2011 at 23:48, Randell Jesup <randell-ietf@jesup.org> wrote:
On 10/12/2011 11:25 AM, Henrik Lundin wrote:
I honestly don't have a lot of love for fully offline, non-real-time simulations like ns2 for this sort of work - the realtime algorithms have often are painful to rework to run paced by the simulation, and to be honest I want a reasonable approximation of a real network, where subjective measurements and evaluation can be quickly done. Plus I find Dummynet/Netem more intuitive than what I know about using ns2 (which I've never actually used, but the comments from Varun Singh make me shudder at using it as a primary tool.
Just to clarify, in our simulation setup, we hooked up an encoder and decoder to the NS2 application. If we were simulating dummy packets then this simulation would run more quickly. The encoder (which runs outside the NS2 context) provides the H.264 frames to the ns2 application where it is fragmented and encapsulated in RTP packets and transmitted over the NS2 topology. At the receiver side ns2 application the RTP packet is passed to a real-world decoder. The main reason for slowness of the simulation is that the ns2 application had to routinely time sync with the codec (outside the NS2). It was more like NS2 polling the codec and saying now is 0ms do you have any data, 5ms, 10ms, 15ms, etc. The advantage of using NS2 is that you can have complex topologies, change the type of links (DSL, WLAN, 3G), queues (drop tail, RED), type of cross-traffic (FTP, CBR, start and stop TCP flows) and easily measure throughput for each flow (making analysis easier). In our setup, we also got a YUV file at the decoder with which we could calculate PSNR and/or play back next to the original YUV.
My preference is for netem and/or dummynet across a bench and also for connecting a device to a corporate or high-speed residential network while simulating a much lower-speed or loaded access link. Hook up a switch or NAT and a PC to run transfers, make VoIP calls, run bittorrent(!!), randomly browse, watch Youtube, etc while making video calls on the target. We also used to have regular residential cable modems as well. Make lots of actual calls where you're talking to someone; humans are very good at picking out most types of errors - especially the ones that matter, and you can also collect statistics while doing so. Combine those tools with a few good testers and you'll find all sorts of funny edge conditions that most straight simulations miss.
IMO dummynet would work but to properly analyze the rate control, we must also analyse the end-to-end throughput (and/or other metrics) of the rtcweb media, link, and other traffic. To make sure that the media is fair to the cross traffic and that the cross traffic doesn't starve the media (e.g., in case of Bittorrent or too many TCP). For most scenarios this should be possible using tcpdump. PlanetLab will be useful if we want to emulate more complex scenarios (like different types of routers etc). For simple cases, using dummynet on a single hop (or at end-points) may be good enough.
IMHO.
5. It appears that the code in remote_rate_control.cc (i.e.receiver) currently starts at the max-configured bitrate; is this correct? What's the impact of this; what does the sender-side start at?
This is correct, and means that the receiver side does not enforce or ask for any rate reduction until it has experienced the first over-bandwidth.
Ok, as per above and Magnus's comments, I tend to disagree with this - it almost guarantees you'll be in recovery right at the start of the call, which is not the best experience for 1-to-1 communication, IMHO (and in my experience). See my extensive discussion of starting bandwidths on rtcweb (I should copy it here for archival).
I think there has been a misunderstanding here. It is true that the code in the receiver-side of the CC algorithm (specifically in remote_rate_control.cc) starts at the max-configured rate. This is while waiting for it to detect the first over-use. However, and this is were the catch is, it does not mean that the sender starts sending at the max rate. In our current implementation, the sender decides the actual start rate. Further, since the original implementation was done based on TMMBR, we had to implement a stand-alone CC at the sender too, since it's not allowed to rely on TMMBR alone. Thus, as long as the TMMBR feedback is larger than what the sender's internal CC says, it will not listen to the TMMBR. Therefore, the receive-side initialization that you see does not mean that we start each call at ludicrous speed. Some of the things in the implementation are legacy...
Ok, good - I thought I'd asked that question when we all were chatting and I probably wasn't specific enough.
Hmmm. Oh well. I guarantee there are devices out there that drift a lot... And even have time go backwards (great fun there).
I'm sure there are. So far we have not seen drift large enough to actually offset the over-/under-use detection.
I'm told some PC audio cards/interfaces have significantly drifty timebases - but perhaps not at a level that matters here. When working with the old GIPS code, we kept a PLL tracking the apparent timebase of each far-end stream, updated on RTCP reports, and reset if something "odd" happens.
-- Randell Jesup randell-ietf@jesup.org _______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
On Thu, Oct 13, 2011 at 12:18 AM, Varun Singh <vsingh.ietf@gmail.com> wrote:
On Wed, Oct 12, 2011 at 23:48, Randell Jesup <randell-ietf@jesup.org> wrote:
On 10/12/2011 11:25 AM, Henrik Lundin wrote:
I honestly don't have a lot of love for fully offline, non-real-time simulations like ns2 for this sort of work - the realtime algorithms have often are painful to rework to run paced by the simulation, and to be honest I want a reasonable approximation of a real network, where subjective measurements and evaluation can be quickly done. Plus I find Dummynet/Netem more intuitive than what I know about using ns2 (which I've never actually used, but the comments from Varun Singh make me shudder at using it as a primary tool.
Just to clarify, in our simulation setup, we hooked up an encoder and decoder to the NS2 application. If we were simulating dummy packets then this simulation would run more quickly. The encoder (which runs outside the NS2 context) provides the H.264 frames to the ns2 application where it is fragmented and encapsulated in RTP packets and transmitted over the NS2 topology. At the receiver side ns2 application the RTP packet is passed to a real-world decoder. The main reason for slowness of the simulation is that the ns2 application had to routinely time sync with the codec (outside the NS2). It was more like NS2 polling the codec and saying now is 0ms do you have any data, 5ms, 10ms, 15ms, etc.
The advantage of using NS2 is that you can have complex topologies, change the type of links (DSL, WLAN, 3G), queues (drop tail, RED), type of cross-traffic (FTP, CBR, start and stop TCP flows) and easily measure throughput for each flow (making analysis easier). In our setup, we also got a YUV file at the decoder with which we could calculate PSNR and/or play back next to the original YUV.
This is what I am looking for. I was primarily considering using some kind of dummy load generator (video and/or audio) to produce flows with the right characteristics (frame rate, frame size variability, I frames, etc.) and inject this into the simulated network. Looking at metrics such as throughput, end-to-end delay and loss rate would provide a lot of insight into how a real media stream would be affected. Thanks for the feedback. It seems ns2 is the weapon of choice.
My preference is for netem and/or dummynet across a bench and also for connecting a device to a corporate or high-speed residential network while simulating a much lower-speed or loaded access link. Hook up a switch or NAT and a PC to run transfers, make VoIP calls, run bittorrent(!!), randomly browse, watch Youtube, etc while making video calls on the target. We also used to have regular residential cable modems as well. Make lots of actual calls where you're talking to someone; humans are very good at picking out most types of errors - especially the ones that matter, and you can also collect statistics while doing so. Combine those tools with a few good testers and you'll find all sorts of funny edge conditions that most straight simulations miss.
IMO dummynet would work but to properly analyze the rate control, we must also analyse the end-to-end throughput (and/or other metrics) of the rtcweb media, link, and other traffic. To make sure that the media is fair to the cross traffic and that the cross traffic doesn't starve the media (e.g., in case of Bittorrent or too many TCP). For most scenarios this should be possible using tcpdump.
PlanetLab will be useful if we want to emulate more complex scenarios (like different types of routers etc). For simple cases, using dummynet on a single hop (or at end-points) may be good enough.
IMHO.
5. It appears that the code in remote_rate_control.cc (i.e.receiver) currently starts at the max-configured bitrate; is this correct? What's the impact of this; what does the sender-side start
at?
This is correct, and means that the receiver side does not enforce or ask for any rate reduction until it has experienced the first over-bandwidth.
Ok, as per above and Magnus's comments, I tend to disagree with this - it almost guarantees you'll be in recovery right at the start of the call, which is not the best experience for 1-to-1 communication, IMHO (and in my experience). See my extensive discussion of starting bandwidths on rtcweb (I should copy it here for archival).
I think there has been a misunderstanding here. It is true that the code in the receiver-side of the CC algorithm (specifically in remote_rate_control.cc) starts at the max-configured rate. This is while waiting for it to detect the first over-use. However, and this is were the catch is, it does not mean that the sender starts sending at the max rate. In our current implementation, the sender decides the actual start rate. Further, since the original implementation was done based on TMMBR, we had to implement a stand-alone CC at the sender too, since it's not allowed to rely on TMMBR alone. Thus, as long as the TMMBR feedback is larger than what the sender's internal CC says, it will not listen to the TMMBR. Therefore, the receive-side initialization that you see does not mean that we start each call at ludicrous speed. Some of the things in the implementation are legacy...
Ok, good - I thought I'd asked that question when we all were chatting and I probably wasn't specific enough.
Hmmm. Oh well. I guarantee there are devices out there that drift a lot... And even have time go backwards (great fun there).
I'm sure there are. So far we have not seen drift large enough to actually offset the over-/under-use detection.
I'm told some PC audio cards/interfaces have significantly drifty timebases - but perhaps not at a level that matters here. When working with the old GIPS code, we kept a PLL tracking the apparent timebase of each far-end stream, updated on RTCP reports, and reset if something "odd" happens.
-- Randell Jesup randell-ietf@jesup.org _______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
-- http://www.netlab.tkk.fi/~varun/ _______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
Hi Henrik, a comment inline. On Thu, Oct 13, 2011 at 09:37, Henrik Lundin <henrik.lundin@webrtc.org> wrote:
On Thu, Oct 13, 2011 at 12:18 AM, Varun Singh <vsingh.ietf@gmail.com> wrote:
On Wed, Oct 12, 2011 at 23:48, Randell Jesup <randell-ietf@jesup.org> wrote:
On 10/12/2011 11:25 AM, Henrik Lundin wrote:
I honestly don't have a lot of love for fully offline, non-real-time simulations like ns2 for this sort of work - the realtime algorithms have often are painful to rework to run paced by the simulation, and to be honest I want a reasonable approximation of a real network, where subjective measurements and evaluation can be quickly done. Plus I find Dummynet/Netem more intuitive than what I know about using ns2 (which I've never actually used, but the comments from Varun Singh make me shudder at using it as a primary tool.
Just to clarify, in our simulation setup, we hooked up an encoder and decoder to the NS2 application. If we were simulating dummy packets then this simulation would run more quickly. The encoder (which runs outside the NS2 context) provides the H.264 frames to the ns2 application where it is fragmented and encapsulated in RTP packets and transmitted over the NS2 topology. At the receiver side ns2 application the RTP packet is passed to a real-world decoder. The main reason for slowness of the simulation is that the ns2 application had to routinely time sync with the codec (outside the NS2). It was more like NS2 polling the codec and saying now is 0ms do you have any data, 5ms, 10ms, 15ms, etc.
The advantage of using NS2 is that you can have complex topologies, change the type of links (DSL, WLAN, 3G), queues (drop tail, RED), type of cross-traffic (FTP, CBR, start and stop TCP flows) and easily measure throughput for each flow (making analysis easier). In our setup, we also got a YUV file at the decoder with which we could calculate PSNR and/or play back next to the original YUV.
This is what I am looking for. I was primarily considering using some kind of dummy load generator (video and/or audio) to produce flows with the right characteristics (frame rate, frame size variability, I frames, etc.) and inject this into the simulated network. Looking at metrics such as throughput, end-to-end delay and loss rate would provide a lot of insight into how a real media stream would be affected. Thanks for the feedback. It seems ns2 is the weapon of choice.
We wrote a very simple packet generator that simulates I and P packets (no B frames). It uses a customizable but fixed GOP size and varying bit rate. IMO this doesn't work well for complex/stress testing, because in the real-world the codecs don't work in such a deterministic way. A lot also depends on the type of content. I agree with Randell Jesup that with a real world implementation it easier to make out video artifacts etc. Our recent experiments with Dummynet and NS2 show that there is some mismatch between the simulations. Dummynet simulations are turning out to be worse off. I am not ruling out that we may have bugs in our simulation setup/RTP code (our NS2 code is more mature) but simple things like RTT variation in case of dummynet is much more than the modelled one in NS2 for constant capacity and CBR media. Which I think may be also true for real-world deployments.
My preference is for netem and/or dummynet across a bench and also for connecting a device to a corporate or high-speed residential network while simulating a much lower-speed or loaded access link. Hook up a switch or NAT and a PC to run transfers, make VoIP calls, run bittorrent(!!), randomly browse, watch Youtube, etc while making video calls on the target. We also used to have regular residential cable modems as well. Make lots of actual calls where you're talking to someone; humans are very good at picking out most types of errors - especially the ones that matter, and you can also collect statistics while doing so. Combine those tools with a few good testers and you'll find all sorts of funny edge conditions that most straight simulations miss.
IMO dummynet would work but to properly analyze the rate control, we must also analyse the end-to-end throughput (and/or other metrics) of the rtcweb media, link, and other traffic. To make sure that the media is fair to the cross traffic and that the cross traffic doesn't starve the media (e.g., in case of Bittorrent or too many TCP). For most scenarios this should be possible using tcpdump.
PlanetLab will be useful if we want to emulate more complex scenarios (like different types of routers etc). For simple cases, using dummynet on a single hop (or at end-points) may be good enough.
IMHO.
5. It appears that the code in remote_rate_control.cc (i.e.receiver) currently starts at the max-configured bitrate; is this correct? What's the impact of this; what does the sender-side start at?
This is correct, and means that the receiver side does not enforce or ask for any rate reduction until it has experienced the first over-bandwidth.
Ok, as per above and Magnus's comments, I tend to disagree with this - it almost guarantees you'll be in recovery right at the start of the call, which is not the best experience for 1-to-1 communication, IMHO (and in my experience). See my extensive discussion of starting bandwidths on rtcweb (I should copy it here for archival).
I think there has been a misunderstanding here. It is true that the code in the receiver-side of the CC algorithm (specifically in remote_rate_control.cc) starts at the max-configured rate. This is while waiting for it to detect the first over-use. However, and this is were the catch is, it does not mean that the sender starts sending at the max rate. In our current implementation, the sender decides the actual start rate. Further, since the original implementation was done based on TMMBR, we had to implement a stand-alone CC at the sender too, since it's not allowed to rely on TMMBR alone. Thus, as long as the TMMBR feedback is larger than what the sender's internal CC says, it will not listen to the TMMBR. Therefore, the receive-side initialization that you see does not mean that we start each call at ludicrous speed. Some of the things in the implementation are legacy...
Ok, good - I thought I'd asked that question when we all were chatting and I probably wasn't specific enough.
Hmmm. Oh well. I guarantee there are devices out there that drift a lot... And even have time go backwards (great fun there).
I'm sure there are. So far we have not seen drift large enough to actually offset the over-/under-use detection.
I'm told some PC audio cards/interfaces have significantly drifty timebases - but perhaps not at a level that matters here. When working with the old GIPS code, we kept a PLL tracking the apparent timebase of each far-end stream, updated on RTCP reports, and reset if something "odd" happens.
-- Randell Jesup randell-ietf@jesup.org _______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
On 10/11/2011 03:11 AM, Henrik Lundin wrote:
I do not agree with you here. When an over-use is detected, we propose to measure the /actual/ throughput (over the last 1 second), and set the target bitrate to beta times this throughput. Since the measured throughput is a rate that evidently was feasible (at least during that 1 second), any beta < 1 should assert that the buffers get drained, but of course at different rates depending on the magnitude of beta.
Take a look at the data from the ICSI netalyzr: you'll find scatter plots at: http://gettys.wordpress.com/2010/12/06/whose-house-is-of-glasse-must-not-thr... Note the different coloured lines. They represent the amount of buffering measured in the broadband edge in *seconds*. Also note that for various reasons, the netalyzr data is actually likely underestimating the problem. Then realise that when congested, nothing you do can react faster than the RTT including the buffering. So if your congestion is in the broadband edge (where it often/usually is), you are in a world of hurt, and you can't use any algorithm that has fixed time constants, even one as long as 1 second. Wish this weren't so, but it is. Bufferbloat is a disaster... - Jim
participants (4)
-
Henrik Lundin -
Jim Gettys -
Randell Jesup -
Varun Singh