On 11/8/2011 8:37 PM, Wesley Eddy wrote:
It's possible to use TFRC in order to compute a bound, and then use a 2nd algorithm with a focus on delay, operating below the bound set by TFRC.
How would TFRC produce a good bound if the delay-based algorithm keeps delay low and avoids loss? And if so, what is using TFRC as a bound doing for you? As far as I can see, just acting as a stopgap against the primary algorithm going haywire, and maybe reacting when there's a sudden bandwidth restriction - but the delay algorithm is likely to be more aggressive in reacting to it. TFRC would see no loss, so it will sit thinking the bandwidth available is 2x the current send rate, roughly. Also, if for some reason you're not trying to pump the channel full of data, TFRC will reduce it's bandwidth estimate, since it's based on X_recv, which is the rate data was received during the last RTT. With codec data, you don't have a queue of data waiting to be sent, so with a short RTT you may get no packets or just an audio packet in the previous RTT. In TFRC, the sender's X_recv_set is "typically" only two entries, or 2 RTT. If the devices are on the same LAN, RTT may be 10ms. Even if you extend X-recv_set, you won't generally have a good bound on bandwidth other than "2x the instantaneous bandwidth most recently seen". But instantaneous bandwidth can be misleading, especially with rate-limited codecs and if you're far from the bottleneck - which is the norm, as the bottleneck is usually the first upstream link, and you're measuring at the other side of the far-end downstream link - dispersed packets can re-aggregate on the faster downstream link. It also makes it impossible to cleanly support bursty transmissions, since bandwidth ramps up (and down) slowly. Bursts after idleness are now allowed in RFC 5348, but only one RTT's worth at the current bandwidth estimate. Since the bandwidth estimate degrades over time if the client is idle for even moderate periods (think chat or in a game when it's not exchanging data with a particular other player, or only at low BW), the value of this burst declines as well - and the value is especially low on LANs and low-RTT settings. (Chat with your neighbor, or with another coworker over WiFi). Realize that delay-based CC is almost by definition more conservative in general than TFRC, so using TFRC as a bound doesn't buy you much if anything, but may cause major problems with bursty use, for example. Think push-to-talk type applications in a game with video - if the bandwidth is there, you want to start using it from the start of the communication, and very quickly adapt if it's not there (adapt both up and down faster than TFRC, and maybe start higher than TFRC, especially if we have history about the connection). The start of a video communication is especially sensitive to low bandwidth and slow ramping/convergence, since a "good" baseline image needs to be received for high-quality efficient pframes to produce a good experience. <IETF contributor hat on> If the spec requires TFRC, implementers will likely use another algorithm underneath it or instead of it (delay-based) and largely or completely ignore formal TFRC even if they offically support it, since actually using TFRC would not produce a sufficiently reliable low-delay, high-quality connection. And that will invite incompatibilities, depending on the choices they make to "improve on" or override TFRC. Note bene: I'm also an implementer. -- Randell Jesup randell-ietf@jesup.org