1 / 14

Coupled congestion control for RTP media

Coupled congestion control for RTP media. draft-welzl-rmcat-coupled-cc- 02 Michael Welzl , Safiqul Islam, Stein Gjessing. RMCAT @ 88th IETF Meeting Vancouver, BC, Canada 6 November 2013. FP7 RITE Reducing Internet Transport Latency. Flow State Exchange (FSE). Flow 1. SBD.

afram
Download Presentation

Coupled congestion control for RTP media

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. Coupled congestion controlfor RTP media draft-welzl-rmcat-coupled-cc-02 Michael Welzl, Safiqul Islam, Stein Gjessing RMCAT @ 88th IETF Meeting Vancouver, BC, Canada6 November 2013 FP7 RITEReducing Internet Transport Latency

  2. Flow State Exchange (FSE) Flow 1 SBD Hoping to have adraft by the next IETF Flow 2 Flow 3 Flow 4 FSE Flow n

  3. Previous version: only passive • Goal: Minimal change to existing CC • each time it updates its sending rate (New_CR), the flow calls update (New_CR, New_DR), and gets the new rate • Complicates the FSE algorithm and resulting dynamics (e.g. need dampening to avoid overshoot by slowly-reacting flows) Update_rate() FSE Flow 1 Store Information New_Rate Update_rate() Flow 2 Calculate Rates New_Rate Update_rate() Flow n New_Rate

  4. Now added: FSE - Active • Actively initiates communication will all the flows • Perhaps harder to use, but simpler algorithm and “nicer” resulting dynamics Update_rate() FSE Flow 1 Store Information New_Rate Flow 2 Calculate Rates New_Rate Flow n New_Rate

  5. Now added: FSE - Active • Actively initiates communication will all the flows • Perhaps harder to use, but simpler algorithm and “nicer” resulting dynamics FSE Flow 1 Store Information New_Rate Update_rate() Flow 2 Calculate Rates New_Rate Flow n New_Rate

  6. Active algorithm • Every time the congestion controller of a flow determines a new sending rate CC_R, the flow calls UPDATE • Updates the sum of all rates, calculates the sending rates for all the flows and distributes them to all registered flows • Essentially all that is left in this version: for all flows i in FG do FSE_R(i) = (P(i)*S_CR)/S_P send FSE_R(i) to the flow I end for • Designed to be as simple as possible • Lacks 1 feature (to be included in the next version): immediately using the capacity freed by application-limited flows

  7. Dynamic behavior: Rate Adaptation Protocol RAP ( = rate-based AIMD) All simulations in this presentation:Dumbbell topology with bottleneck 10Mb, 1 BDP (13 packets) drop tail queue,RTT = 10 ms, duration 300 seconds With FSE Without FSE

  8. Dynamic behavior: TFRC With FSE Without FSE

  9. FSE goals • Charter:“Develop a mechanism for identifying shared bottlenecks between groups of flows, and means to flexibly allocate their rates within the aggregate hitting the shared bottleneck.”(requirement F34 in draft-ietf-rtcweb-use-cases-and-requirements-12) • This works perfectly • Also did in the previousversion • But: because this avoids competition between flows, we expect reduced queuing delay and loss as a side effect Priority of flow 1 increased over time

  10. Average queue length (RAP)

  11. Packet loss ratio (RAP)

  12. What’s going on? • Queue drains more often without FSE • Thought behind expected benefits: coupling emulates one flow • But, e.g.: 2 flows with rate X each; one flow halves its rate: 2X  1 ½X • When flows synchronize, both halve their rate on congestion, which really halves the aggregate rate: 2X 1X With FSE Without FSE

  13. Current work • Trying to fix this (proportionally reduce aggregate rate on congestion, but increase by delta/N) • Some issues, e.g. slow start • Why do we have these problems? • Because all papers on RFC2140 etc. did not focus on reducing queuing delay • RFC2140 cwnd sharing probably has the same problem

  14. Q&A

More Related