Coupled congestion control for rtp media
Download
1 / 14

Coupled congestion control for RTP media - PowerPoint PPT Presentation


  • 116 Views
  • Uploaded on

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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Coupled congestion control for RTP media' - afram


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Coupled congestion control for rtp media

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


Flow state exchange fse
Flow State Exchange (FSE)

Flow 1

SBD

Hoping to have adraft by the next IETF

Flow 2

Flow 3

Flow 4

FSE

Flow n


Previous version only passive
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


Now added fse active
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


Now added fse active1
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


Active algorithm
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


Dynamic behavior rate adaptation protocol rap rate based aimd
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


Dynamic behavior tfrc
Dynamic behavior: TFRC rate-based AIMD)

With FSE

Without FSE


Fse goals
FSE goals rate-based AIMD)

  • 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


Average queue length rap
Average queue length (RAP) rate-based AIMD)


Packet loss ratio rap
Packet loss ratio (RAP) rate-based AIMD)


What s going on
What’s going on? rate-based AIMD)

  • 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


Current work
Current work rate-based AIMD)

  • 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


Coupled congestion control for rtp media

Q&A rate-based AIMD)