- Rtp-congestion - alvestrand.no

RTCWEB Congestion control Standardization (repost)
by Randell Jesup 27 Oct '11

27 Oct '11

Harald pointed out that my first posting of this was officially a reply to an earlier message that some may have missed, so I'm reposting as a top-level item. -- Randell On 10/10/2011 5:22 AM, Magnus Westerlund wrote: > So what are our alternative here? > > 1) Pick TFRC for now while developing something better? Possibly ensure > that the RTP mapping gets published in a reasonable time frame. > > 2) Try to write clear requirements on the implementation, but no > specification and hopes that goes through? > > 3) Develop something and delay the publication of any part that needs > this until it is done? > > 4) ? > > Regarding 3), I don't see how that is going to complete in less than 2 > more likely 3 years. Spin up a TSV WG, develop a solution. Simulate and > discuss corner cases for a while before getting good enough out. I vote for 2, and provide a sample implementation and let people innovate. I would also support trying to standardize the sample implementation under 3 in parallel, with the understanding it will take A Long Time. Here's a set of proposed stab at requirements for rtcweb implementations: As part of rtcweb, congestion control must be addressed: 1. All WebRTC media and data streams MUST be congestion-controlled. 2. The congestion algorithms used MUST cause WebRTC streams to act fairly with TCP and other congestion-controlled flows, such as DCCP and TFRC, and other WebRTC flows. Note that WebRTC involves multiple data flows which "normally" would be separately congestion-controlled. 3. In order to support better overall user experiences and to allow applications to have better interaction with congestion control, a new AVPF feedback message [ insert name here] shall be defined to allow reporting of total predicted bandwidth for receiving data, as opposed to TMMBR, which requests a sending rate for a single SSRC flow. [ This is roughly equivalent to b=CT:xxx ] We may want to give the estimation algorithm the option to not include or exclude the data-channel bandwidth, but it SHOULD include that. 4. In order to facilitate better operation of bandwidth-estimation algorithms on the receiving side, the sending side MAY include a transmit-time RTP header extension (TBD) to some or all media streams. Note that this will add about 12 bytes to each RTP packet. An optimization may be to only include these timestamps if they deviate by more than [ some amount TBD from the running average and from the number of bytes preceding it with the same timestamp ]. This is based on the fact that for many devices, the sample->send interval is fairly consistent at the levels of accuracy needed here, and so significant bandwidth savings can be made. 5. The receiver SHOULD attempt to minimize the number of bandwidth reports when there is little or no change, while reporting quickly when there is a significant change. 6. Congestion control MUST work even if there are no media channels, or if the media channels are inactive in one or both directions. 7. The congestion control algorithm SHOULD attempt to keep the total bandwidth controlled so as to minimize the media- stream end-to-end delays between the participants. 8. When receiving a [ insert new AVPF message here ], the sender shall attempt to comply with the overall bandwidth requirements by adjusting parameters it can control, such as codec bitrates and modes, and how much data is sent on the data channels. Not part of our IETF requirements, at the JS level bandwidth changes should be reported to the application along so that it has the option to make changes that we can't make automatically, such as removing or adding a stream, or controlling the parameters of a stream (frame rate, etc). Note that if the application doesn't do anything, the automatic adaptation will still occur. -- Randell Jesup randell-ietf(a)jesup.org

1 0

Strawman: Requirements
by Harald Alvestrand 20 Oct '11

20 Oct '11

I think that in order to get off ground zero here, both in implementation, testing and navigating the tortuous path towards standards-track adoption, we should throw out some requirements. And in the spirit of rushing in where angels fear to tread, I'm going to throw out some. MEASUREMENT SETUP Imagine a system consisting of: - A sender A attached to a 100 Mbit LAN, network X - A bandwidth constricted channel between this LAN and another LAN, having bandwidth BW - A recipient B also attached to a 100 Mbit LAN, network Y - A second sender A' attached to network X, also sending to B - Other equipment that generates traffic from X to Y over the channel All measurements are taken by starting the flows, letting the mechanisms adapt for 60 seconds, and then measuring bandwidth use over a 10-second interval. This seems like the simplest reasonable system. We might have to specify the buffer sizes on the border routers to get reproducible results. PROTOCOL FUNCTIONS ASSUMED AVAILABLE The sender and recipient have a connection mediated via ICE, protected with SRTP. The following functions need to be available: - A "timestamp" option for RTP packets as they leave the sender - A "bandwidth budget" RTCP message, signalling the total budget for packets from A to B REQUIRED RESULTS In each measurement scenario below, the video signal must be reproducible, with at most 2% measured packet loss. (this is my proxy for "bandwidth must have adapted"). If A sends one video stream with max peak bandwidth < BW, and there is no other traffic, A will send at the maximum rate for the video stream. ("we must not trip ourselves up"). If A and A' each send two video streams with MPB > 1/2 BW, the traffic measured will be at least 30% of BW for each video stream. ("we must play well with ourselves") If A sends a video stream with MPB > BW, and there is a TCP bulk transfer stream from LAN X to LAN Y, the TCP bulk transfer stream must get at least 30% of BW. ("be fair to TCP") If A sends a video stream with MPB > BW, and there is a TCP bulk transfer stream from LAN X to LAN Y, the video stream must get at least 30% of BW. ("don't let yourself be squeezed out") Mark - this is almost completely off the top of my head. I believe that failing any of these things will probably mean that we will have a system that is hard to deploy in practice, because quality will just not be good enough, or the harm to others will be too great. There are many ways of getting into trouble that won't be detected in the simple setups below, but we may want to leave those aside until we've shown that these "deceptively simple" cases can be made to work. We might think of this as "test driven development" - first define a failure case we can measure, then test if we're failing in that particular way - if no; proceed; if yes; back to the drawing board. What do you think? Harald

6 17

Re: [R-C] Congestion Control BOF
by Varun Singh 19 Oct '11

19 Oct '11

Hi, On Sat, Oct 8, 2011 at 17:53, Randell Jesup <randell(a)jesup.org> wrote: >> Do you think we want to aim for a separate "bar BOF" in Taipei on the >> subject? > > > Sure, but I'm afraid I won't be there - perhaps electronically. If there is sufficient interest and people at the IETF82 then I support meeting and discussing this face-to-face. Regards, Varun

2 1

bufferbloat-induced delay at a non-bottleneck node
by Randell Jesup 14 Oct '11

14 Oct '11

Jim: We're moving this discussion to the newly-created mailing sub-list - Rtp-congestion(a)alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion If you'd like to continue this discussion (and I'd love you to do so), please join the mailing list. (Patrick, you may want to join too and read the very small backlog of messages (perhaps 10 so far)). On 10/11/2011 4:17 PM, Jim Gettys wrote: > 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-th… > > 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. Understood. Though that's not entirely relevant to this problem, since the congestion-control mechanisms we're using/designing here are primarily buffer-sensing algorithms that attempt to keep the buffers in a drained state. If there's no competing traffic at the bottleneck, they're likely to do so fairly well, though more simulation and real-world tests are needed. I'll note that several organizations (Google/GIPS, Radvision and my old company WorldGate) had found that these types of congestion-control algorithms are quite effective in practice. However, it isn't irrelevant to the problem either: This class of congestion-control algorithms are subject to "losing" if faced with a sustained high-bandwidth TCP flow like some of your tests, since they back off when TCP isn't seeing any restriction (loss) yet. Eventually TCP will fill the buffers. More importantly, perhaps, bufferbloat combined with the high 'burst' nature of browser network systems (and websites) optimizing for page-load time means you can get a burst of data at a congestion point that isn't normally the bottleneck. The basic scenario goes like this: 1. established UDP flow near bottleneck limit at far-end upstream> 2. near-end browser (or browser on another machine in the same house) initiates a page-load 3. near-end browser opens "many" tcp connections to the site and other sites that serve pieces (ads, images, etc) of the page. 4. Rush of response data saturates the downstream link to the near-end, which was not previously the bottleneck. Due to bufferbloat, this can cause a significant amount of data to be temporarily buffered, delaying competing UDP data significantly (tenths of a second, perhaps >1 second in cases). This is hard to model accurately; real-world tests are important. 5. Congestion-control algorithm notices transition to buffer- induced delay, and tells the far side to back off. The latency of this decision may help us avoid over-reacting, as we have to see increasing delay which takes a number of packets (at least 1/10 second, and easily could be more). Also, the result of the above "inrush"/pageload-induced latency may not trigger the congestion mechanisms we discuss here, as we might see a BIG jump in delay followed by steady delay or a ramp down (since if the buffer has suddenly jumped from drained to full, all it can do is be stable or drain). Note that Google's current algorithm (which you comment on above) uses recent history for choosing the reduction; in this case it's hard to say what the result would be: if it invokes the backoff at the start of the pageload, then the bandwidth received recently is the current bandwidth, so the new bandwidth is current minus small_delta. If it happens after data has queued behind the burst of TCP traffic, then when the backoff is generated we'll have gotten almost no data through "recently" and we may back off all the way to min bandwidth; an over-reaction, depending on the time constant and level of how fast that burst can fill the downstream buffers. Now, in practice this is likely messier and the pageload doesn't generate a huge sudden block of data that fills the buffers, so there's some upward slope to delay as you head to saturation of the downstream buffers. And there's very little you can do about this - and backing off a lot may help in that the less data you put onto the end of this overloaded queue (assuming the pageload flow has ended or soon will), the sooner the queue will drain and low-latency will be re-established. Does the ICSI data call out *where* the buffer-bloat occurs? > 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... Given the loss-based algorithms for TCP/etc, yes. We have to figure out how to (as reliably *as possible*) deliver low-latency data in this environment. -- Randell Jesup randell-ietf(a)jesup.org

3 7

Re: [R-C] Congestion Control BOF
by Henrik Lundin 13 Oct '11

13 Oct '11

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(a)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/so… > ) > > > #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) > > > > >

4 8

Re: [R-C] [rtcweb] Congestion Control proposal
by Randell Jesup 12 Oct '11

12 Oct '11

Inline below... We should probably move this to rtp-congestion. On 10/11/2011 11:35 AM, Colin Perkins wrote: > On 7 Oct 2011, at 22:37, Randell Jesup wrote: >> On 10/7/2011 3:12 PM, Colin Perkins wrote: >>> [inline] >>> >>> On 6 Oct 2011, at 16:32, Randell Jesup wrote: >>> ... >>>> Startup: >>>> >>>> There are issues both with starting too low (quality is poor at the start and takes a while to get better), and with starting too high (you immediately can get into a delay situation and have to go into recovery). In general, starting too low is better than starting too high, as when we ramp up past the bottleneck we will not be too far over the limit and so recovery will be easier. In general, the bottleneck link is often upstream, though this is moderating as high-bandwidth broadband becomes more common. >>>> >>>> Options include: >>>> a) Start at fixed value >>>> b) Start at N% below the value from the last call with this person >>>> (probably requires the App to help here) >>>> c) Start at N% below the value from the last call with anyone >>>> d) Have the other side tell us the rate they successfully received in the >>>> last call. Start the call at the lower of the last-call reception >>>> rate from the far end or our last-call sending rate, minus n% >>>> e) probe bandwidth at or before the start of the call using a packet >>>> train >>>> >>>> 'a' will be quite sub-optimal for most cases, though if the value is low enough it won't be over-bandwidth. Some applications (games, etc) may want to limit the starting bandwidth to avoid negative interactions with other dataflows. >>>> >>>> 'b' has a problem that if the last call had a much higher bottleneck bandwidth (especially on the remote downstream), the new call may be over-bandwidth, perhaps badly. This won't be the norm, but may happen especially with mobile/wifi at either end. >>>> >>>> 'c' has a problem that if the last callee had a much higher bottleneck bandwidth (especially on the remote downstream), the new call may be over-bandwidth, perhaps badly. If the caller's upstream bandwidth is high compared to typical downstream bandwidth, then the likelihood of starting over-bandwidth is high. >>>> >>>> 'd' has the advantage of selecting an appropriate value regardless of whether the bottleneck is on upstream or downstream. The downside of 'd' is that the bottlenecks may have changed since the last call in which case we may start over-bandwidth. The historical data could be transferred via pre-call signalling. >>>> >>>> 'e' allows direct measurement of the current call bottlenecks. However 'e' can be misled if a mid-call router that isn't the bottleneck buffers the packet train while housekeeping or doing other operations and then releases them (it can collapse the signal from an earlier bottleneck). It would need to be combined with starting on the low side until a valid measurement is completed. Single measurements are imprecise with packet trains. >>> For a new call, the only safe approach for the network would seem to be option (a), starting at a low rate, followed by a fairly rapid increase in rate to find the safe operating point (i.e., mirroring TCP slow start in concept, if not in detail). The low rate would be chosen to support the voice channel, presumably, so the call is useful immediately, but might then take several RTTs to ramp up to a high enough rate for video to be usable. An initial delay on the video is not an ideal user experience, but I don't see it as being especially problematic provided the voice channel is usable immediately, and we don't seem to have safe options for avoiding it. >> I understand your concern, and agree one should start "low" - but I also feel that for many applications and many users, this would be an over-conservatism that would seriously degrade a very important point in a communication. That initial "answer" behavior had a big impact on the user experience and in the end, utility to the user. In "most" calls (I'd guess for residential desktop browsers>95%, laptops>70% though much more variable) the bottleneck will be the same or similar to the last call - the local upstream, which is fairly constant. >> >> There are users and use-cases where this consistency will not apply - mobile laptop users (when away from desk/office), tablet/handsets. I will note that in most of these cases the change in bottleneck will tend to be less than 2x, so major changes in bandwidth will be fairly uncommon. (You can get a hint on this by checking for external IP address changes!) >> >> In most videophones and soft clients that I've looked at, they have a configured bitrate set by the user and either start at that bitrate, or start at a fraction of that bitrate. At WorldGate, we started at a sliding percentage of the configured bandwidth - a higher percentage at low bandwidths, and down to 50% of configured at high bandwidths, combined (as you suggest) with a much higher ramp-up rate (and faster/further cut-back on problems) for the first seconds of the call. >> >> These things, taken together, make we want to be a bit more aggressive at using history, and perhaps also use the recent N calls' variance in bottleneck rate as a guide (if they're all good at higher rates, start at 50 or 60% of the average; if there's a lot of variance (laptop moving around) use not the last call, but perhaps the lowest quartile or 10th minus 10 or 20%. >> >> Also - this is something that I strongly feel should not be normative. This is guidance and I do feel that there is a place for the application to provide input and/or user preference here. I think we *should* provide guidance and defaults. > I'm hesitant to accept the argument that bottleneck bandwidth is likely to be roughly consistent, so we can start at a rate near that bandwidth. There's getting to be a lot more mobile devices that can switch between WiFi and 3G links with potentially very different capacity, and even ADSL lines can be highly variable with time of day and other users on the same link. As a result, if we are to use history, I think we need normative rules for how, so we at least limit the amount and duration of any damage caused when the history-derived bandwidth estimate is wrong. Hopefully we can identify most of the interface changes such as you mention (IP address changes, OS notification, etc). But even if we can't (ADSL or cable modem upstream variability), the algorithm is adaptive; the downside of starting too high is that it quickly sees that packets arrive at the destination slower than they should; so roughly (depending on RTT) a fractional second or perhaps in some cases a second or two will go by before low-latency within-bandwidth communication is established. And if we're only a little over it may not be very noticeable. And as I suggested, if you start at a significant reduction from expected bandwidth (I generally would recommend 20-30% below at "low" bandwidths, and up to 50-60% reduction at "high" bandwidths), the odds of being over the actual limit, especially in the ADSL/Cable cases is low. >>> Using a packet pair/train to get an estimate of the available bandwidth is appealing, but I'm unconvinced it's accurate enough to be reliable. We've done packet pair measurements to residential links that show extremely inaccurate (high) bandwidth estimates in many cases, so I wouldn't trust that as an initial sending rate. Using a longer packet train would improve accuracy, but at the cost of loading the path, and potentially disrupting any traffic sharing the path. I'm not sure such a bandwidth estimate is that worthwhile if it delays/disrupts the start of the voice channel. >> >> I am likewise leery of packet trains, especially short start-of-call trains. They're interesting, but as you mention they don't seem reliable enough. >> >>> When restarting a previously application limited flow after some short pause in transmission (e.g., the centralised video mixer scenario, where only the active speaker sends video to the mixer), then I'm much more comfortable with restarting at or near the previous rate, provided there's been no indication that the path has changed. The rationale here is that you've had some recent indication that the path can support the rate, but with a new connection, even if to someone you've previously spoken with, there's much less of a guarantee that the available bandwidth is consistent with the previous observation. >> >> Agreed. >> >>>> Even if the data flows are separately congestion controlled, in many uses >>>> they will be non-continuous flows (discrete messages as opposed to data or >>>> file transfers). These sorts of channels have different needs and >>>> different impacts on the media channels from continuous flows: they're >>>> bursty; low delay is important (especially on the initial packet for a >>>> burst, which is often the only packet), and without a steady stream >>>> congestion control will have little effect - and will have little impact on >>>> the media flows. For small bursts of data traffic, the "right" solution >>>> may be to simply ignore them up to some limit, and above that limit start >>>> to subtract the data channel usage from the available bandwidth for >>>> variable-rate encoders. >>>> >>>> The problem here will be defining "small". This will need to be tested and >>>> simulated so we know the impacts of different data usage patterns. I'll >>>> throw a straw-man proposal out there: if the increase in data usage over >>>> the last 1/2 second is below 20% of the total estimated channel bandwidth, >>>> no adjustment to the media channels shall be done, and normal congestion >>>> control mechanisms will be allowed to operate with no interference. Above >>>> that value, the media channels if possible will be adjusted down in >>>> bandwidth by some amount related to the increase in data channel bandwidth. >>>> >>>> The reason for using the increase in bandwidth here is that for steady >>>> flows, normal congestion control should operate well; the problem is when >>>> you have a spike in bandwidth use - the latency in reaction may be longer >>>> than the duration of the burst, and hurt end-to-end delay in the meantime. >>>> So when there's a sudden jump in data bandwidth, you temporarily offset >>>> media down to keep delay and buffering under control. You could also >>>> increase media bitrates if a steady flow suddenly drops, though normal >>>> congestion control mechanisms should use the now-available bandwidth >>>> quickly on their own. >>> Is there some way of measuring the spare queueing capacity of the path, perhaps by periodic probing? To define "small" in a way that's meaningful to the path, we'd be looking at a burst that can be queued in the network without causing excessive delay or queue overflow/loss. Using "1/2 second" or "20%" seems too arbitrary. >> >> It may be possible to use naturally-occuring bursts (or slightly artificially-contrived bursts) to probe the channel. For example, periodic or error-recovery iframes amount to a fairly large burst of large packets; measuring the dispersion at the reception end may will give you a reasonable estimate of unused bandwidth. (I'll note that if you don't have access to the raw network interface this might be a little noisier). > Unused bandwidth might be less important than unused queuing capacity. I'm not sure we care about unused queuing capability at all - we want to stay out of the queue. We are interested in how far below the limit where queuing begins we are. >>>> JS Interface: >>>> >>>> We need to tell the application about bandwidth changes, and give it the >>>> option of making choices, both in the allocation of bits among the various >>>> streams of data, and of the actual streams themselves (adding or shutting >>>> down streams, or switching modes (mono/stereo, codecs possibly, etc)). If >>>> the application doesn't care to make a choice we'll do it for them. We'll >>>> also want the JS application to be able to affect the congestion-control >>>> status of the data channels, so it could take bits from the data channels >>>> without engendering a tug-of-war and temporary over-bandwidth/buffering. >>>> >>>> There are inherent delays to some of these actions by the app, and in an >>>> over-bandwidth case we need to reduce bandwidth *now*, so we may want to >>>> have the "I'm over-bandwidth" case start by automatically reducing >>>> bandwidth if possible, and inform the JS app of the reduction and let it >>>> rebalance or change the details or nature of the call. >>>> >>>> We could use some good straw-men proposals for an API here to the JS code. >>> The right model might be for the application to communicate policy for how to adapt, which the browser then implements. Putting Javascript in the congestion control loop is a concern because of the slow response, which runs the risk of causing oscillation. If we can let the browser run the rate adaption mechanism that's more likely to be stable, and leave the slower Javascript to make the decision about adaptation policy. >> >> Agreed, though some of the adaptations have to occur at the application level (turning off channels, which may involve UI changes, etc). That was why I suggested we adapt using defaults (and any hints given ("policy" in your post)), and then inform the JS app of the change and allow it to rebalance or re-allocate the BW usage, or to change the already-made decisions. This helps guarantee we have working defaults and response speed. >> >> I fear if we try to push all that logic down into the media code it becomes too complex, because you have to anticipate any way an application might want to react, and provide it (and test it). > > Agree. There's clearly a balance to be got here. The main point is that the javascript can be in the control loop, since it's operating at a slower timescale. > -- Randell Jesup randell-ietf(a)jesup.org

1 0

Re: [R-C] RTCWEB Congestion Control Standardization
by Tim Panton 10 Oct '11

10 Oct '11

On 10 Oct 2011, at 10:22, Magnus Westerlund wrote: > Hi, > > I want to lift an important non-technical topic for discussion. Namely, > what is needed in the specifications and how to get that to happen. > > > It is clear that RTCWEB can't be the home to specify any new congestion > control algorithms or procedures. That needs to be defined elsewhere. > > Looking at what is available from a specification point of view, I think > the only that is fully specified for RTP is TFRC in DCCP. > > The technical discussion appears to be desiring something else. Thus I > think we need to have the discussion of how to get that written up in a > specification eventually. What is the plan here? From my perspective we > will need something that is acceptable to get the RTCWEB's RTP usage > specification through IESG. Especially as we have identified clear > security threats to no having congestion control in the browser part > preventing significant over uses. > > So what are our alternative here? > > 1) Pick TFRC for now while developing something better? Possibly ensure > that the RTP mapping gets published in a reasonable time frame. > > 2) Try to write clear requirements on the implementation, but no > specification and hopes that goes through? > > 3) Develop something and delay the publication of any part that needs > this until it is done? > > 4) ? > > Regarding 3), I don't see how that is going to complete in less than 2 > more likely 3 years. Spin up a TSV WG, develop a solution. Simulate and > discuss corner cases for a while before getting good enough out. > > So what are your views on this issue? I would go for 2) If at all possible we should come up with requirements that are such that they can be independently implemented at each end of the P2P 'connection' - any necessary interaction between the ends should be part of a pre-existing specification (SRTP, RTCP or whatever) which we can reference. This would leave the browser vendors clear to implement those requirements however they see fit while minimising risk of interop problems between browsers. I don't know if this is do-able from a technical standpoint. Tim.

2 1