Desired Solution Properties of RTCWEB Congestion Controllers

1. Desired Solution Properties of RTCWEB Congestion Controllers HaraldAlvestrand, Lars Eggert & RandellJesupIAB/IRTF Workshop onCongestion Control for Interactive Real-Time CommunicationIETF-84, Vancouver, CanadaJuly 28, 2012

2. “Desired Solution Properties” • i.e., not the traditional IETF-style MUST/SHOULD/MAY requirements – yet • It’s too early for this • But we should try and identify which properties of solutions are at what level of desirability – and difficulty • Unlikely that we’ll have solutions that fulfill all desires

3. Approach • One slide per property • Did not attempt to be complete, let’s add to this • Indicate our (my) feeling about desirability • Indicate our (my) feeling about difficulty • All up for discussion, just an attempt to survey the papers and summarize

4. Architectural Soundness • Meta-property • We need pick an approach to solving this problem that • Allows us to quickly design and deploy an initial mechanism that is simple, understood and has good-enough behavior • Allows us to incrementally refine and improve the mechanism(s) over potentially a long time • c.f., TCP & Premature optimization is the root of all evil • It’s much more about identifying which congestion-relevant information will be available and on what timescales that it is about building an algorithm

5. Implementability in the browser • No brainer, we need this • Means that we’re sitting above the union set of the features of the socket APIs of different platforms • Hard to access QoS, ECN, ICMP, etc. APIs • Hard != impossible, but may require more platform-specific code than CC guys like

6. Widely Varying Path Characteristics • The Internet is not only DSL and cable, nor only mobile • Path characteristics (delay, loss, available bandwidth, bottleneck queue scheduler, etc.) are widely varying and only going to get more diverse • Even over the same path over increasingly shorter timescales • We need mechanisms that can quantify the current path characteristics accurately and quickly • We need mechanisms that can react to changes in path characteristics accurately (avoid over/undershoot) and quickly (more or less)

7. Internet Technology Drift • Current Internet has bufferbloat, FIFO, TCP Reno • Future Internetmay have CoDel, DiffServ, IW10, ECN/CONEX, QoS, SDN, etc. (on some paths) • This changes the availability and behaviour of feedback signals that will be available in the future • We like mechanisms that use signals that are likely to remain available, that can incorporate/work with new signals • Amenable to benchmarking under changed conditions • Instrumentation to tell if new situations occur

8. Media is not Data • Bitrate/quality relation is not linear • Sudden changes in required bitrate happen • I-frames, movement, silence/speech transitions • We want an integrated congestion controller • Reduce bitrate of streams that can spare it • Add bitrate to streams that benefit • Sounds great, but not so straightforward • What defines the bundle over which to operate?

9. Self-Interference • Even with an integrated CC, independently-controlled (bundles of) flows will meet in the network • Maybe even emitted by a single host (several browsers running) • We need to compete with ourselves “fairly” • (More about this later)

10. Cross Traffic • There will be other flows sharing (part of) the path • CBR, any TCP flavor ever devised, all kinds of other weird stuff • Generated on the same hosts we run on or showing up on the path from elsewhere • We want to • Keep the delay low • Get enough capacity for good media QoE • This is really hard • Other flows happily drive the delay up (if QM that lets them) • Other flows may have a bandwidth equilibrium point that is different from ours • How to be “fair” to other traffic we know nothing about?

11. Fairness • Fairness != flow-rate fairness • For TCP, more bandwidth is always better • Not so for media; more bandwidth becomes increasingly less useful • What properties do make sense? Maybe: • Avoid repeatedly rapid changes in bandwidth use • Avoid starving other traffic (but how to detect?) • Avoid being starved by other traffic (but how to prevent?) • Long shopping list of stuff that could help • AQM, QoS, DiffServ, etc. • But can’t depend on any of them (right now)