Coupled conges-on control for RTP media dra$-­‐welzl-­‐rmcat-­‐coupled-­‐cc-­‐02 Michael Welzl, Safiqul Islam, Stein Gjessing RMCAT @ 88th IETF Mee/ng Vancouver, BC, Canada 6 November 2013 FP7 RITE Reducing Internet Transport Latency 1 Flow State Exchange (FSE) Hoping to have a draT by the next IETF Flow 1 SBD Flow 2 Flow 3 Flow 4 FSE Flow n 2 Previous version: only passive •  Goal: Minimal change to exis/ng CC –  each /me 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 resul/ng dynamics (e.g. need dampening to avoid overshoot by slowly-­‐reac/ng flows) Update_rate() Store Informa/on New_Rate Flow 1 Update_rate() Calculate Rates FSE Flow 2 New_Rate Update_rate() Flow n New_Rate 3 Now added: FSE -­‐ Ac/ve •  Ac/vely ini/ates communica/on will all the flows –  Perhaps harder to use, but simpler algorithm and “nicer” resul/ng dynamics Update_rate() Store Informa/on Calculate Rates New_Rate FSE Flow 1 Flow 2 New_Rate New_Rate Flow n 4 Now added: FSE -­‐ Ac/ve •  Ac/vely ini/ates communica/on will all the flows –  Perhaps harder to use, but simpler algorithm and “nicer” resul/ng dynamics Store Informa/on New_Rate Flow 1 Update_rate() Calculate Rates FSE Flow 2 New_Rate New_Rate Flow n 5 Ac/ve algorithm •  Every /me the conges/on 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 •  Essen/ally all that is leT 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 applica/on-­‐limited flows Dynamic behavior: Rate Adapta/on Protocol RAP ( = rate-­‐based AIMD) 7
7
Flow 1
Flow 2
6
Sending Rate (Mbps)
Sending Rate (Mbps)
6
Flow 1
Flow 2
5
4
3
5
4
3
2
2
20
21
22
23
Time (s)
With FSE 24
25
20
21
22
23
Time (s)
Without FSE 24
25
Dynamic behavior: TFRC 6
6
Flow 1
Flow 2
5.5
Sending Rate (Mbps)
Sending Rate (Mbps)
5.5
Flow 1
Flow 2
5
4.5
5
4.5
4
4
20
21
22
23
Time (s)
With FSE 24
25
20
21
22
23
Time (s)
Without FSE 24
25
FSE goals •  Charter: “Develop a mechanism for iden/fying shared boclenecks between groups of flows, and means to flexibly allocate their rates within the aggregate hidng the shared bocleneck.” (requirement F34 in dra$-­‐ieA-­‐rtcweb-­‐use-­‐cases-­‐and-­‐requirements-­‐12) 10
Flow 1
Flow2
8
Sending Rate (Mbps)
–  This works perfectly –  Also did in the previous version Priority of flow 1 increased over /me 6
4
2
0
50
100
150
Time(s)
200
250
300
•  But: because this avoids compe//on between flows, we expect reduced queuing delay and loss as a side effect Average queue length (RAP) 12
FSE
Without FSE
11
Average Queue Length
10
9
8
7
6
5
4
3
2
4
6
8
10
12
Number of Flows
14
16
18
20
Packet loss ra/o (RAP) 30
FSE
Without FSE
25
Packet Loss Ratio %
20
15
10
5
0
2
4
6
8
10
12
Number of Flows
14
16
18
20
14
14
12
12
10
10
Queue size (pkts)
Queue size (pkts)
What’s going on? 8
6
8
6
4
4
2
2
0
0
15
15.5
16
16.5
17
17.5
18
18.5
19
15
Time (s)
With FSE 15.5
16
16.5
17
17.5
18
18.5
Time (s)
Without FSE •  Queue drains more oTen 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 conges/on, which really halves the aggregate rate: 2X è 1X 19
Current work •  Trying to fix this (propor/onally reduce aggregate rate on conges/on, 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 Q&A