1 / 11

Desired Solution Properties of RTCWEB Congestion Controllers

Desired Solution Properties of RTCWEB Congestion Controllers. Harald Alvestrand , Lars Eggert & Randell Jesup IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication IETF-84, Vancouver, Canada July 28, 2012. “Desired Solution Properties”.

brasen
Download Presentation

Desired Solution Properties of RTCWEB Congestion Controllers

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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)

More Related