Coupled Conges,on Control for RTP Media Safiqul Islam, Michael Welzl, Stein Gjessing and Naeem Khademi Department of Informa,cs University of Oslo Problem statement Each Flow has its own Conges@on Control module Flow 1!
Flow 2!
CC CC CC Flow 3!
Flow n!
Compe,,on leads to: •
•
•
•
More queue g
row
More packet d th rops More delay Fairness prob
lems in case o
f heterogeneou
s RTTs 2 Problem statement – cont. Flow 1!
Flow 2!
CC Single Conges,on Controller CC CC Flow 3!
Flow n!
3 Coupled CC – related work Flow 1!
Flow 2!
Flow 3!
CC Single Conges,on Controller Best known, perhaps the oldest related work. Hard to implement: CC •  Provides a common conges,on framework CC •  Uses a scheduler to distribute the available bandwidth. •  U,lizes the concept of Transport Control Block (TCB) informa,on sharing from RFC2140. Conges,on Manager – RFC 3124 Ensemble TCP -­‐ ETCP Ensemble Flow Conges,on Management Flow n!
4 Shared boUlenecks •  Coupled CC only makes sense across a common boUleneck –  This was ignored in prior work –  But how to know? 1.  Mul,plexing (same 5-­‐, actually 6-­‐tuple) –  Fits rtcweb (coupled-­‐cc proposed in rmcat) – but only for same source/des,na,on hosts 2.  Configura,on (e.g. common wireless uplink) 3.  Measurement –  Never 100% reliable, but: different receivers possible! –  Historically considered imprac,cal, but recent work: David Hayes, Simone Ferlin-­‐Oliveira, Michael Welzl: "Prac=cal Passive Shared Bo?leneck Detec=on Using Shape Summary Sta=s=cs", accepted for publica=on, IEEE LCN 2014, 8-­‐11 September 2014
5 Coupled CC Flow 1!
Single Conges,on Controller Flow 2!
Flow 3!
Flow n!
This might work well for flows having same tuple but what happens when boUleneck changes? 6 Coupled CC Flow 1!
Flow 2!
Flow 3!
Single Conges,on Controller Single Conges,on Controller •  Add another CC? •  Add another scheduler? •  What about previous CC. state? What we think: •  BeUer to have a simple algorithm that loosely couples exis,ng cc with minimal changes. Flow n!
7 Coupled CC Flow 1!
Flow 2!
CC Flow State Exchange (FSE) CC CC Flow 3!
Flow n!
8 The Flow State Exchange (FSE) Sender Host Flow 1 cc FSE Flow 2 cc Flow 3 cc Shared BoUleneck Detec,on (SBD) Flow n cc 9 The Flow State Exchange (FSE) Sender Host Update_Rate ()
Store Informa,on New_Rate
Flow 1 cc Flow 2 cc Calculate Rate FSE Flow n cc 10 The Flow State Exchange (FSE) Sender Host Store Informa,on Flow 1 cc Update_Rate ()
Calculate Rate New_Rate
Flow 2 cc FSE Flow n cc 11 Simple algorithm •  Every ,me the conges,on controller of a flow determines a new sending rate, the flow calls UPDATE •  FSE updates the sum of all rates, calculates the sending rates for all the flows and distributes them for all flows i in FG do FSE_R(i) = (P(i)*ΣCR)/ΣP send FSE_R(i) to the flow I end for •  Results were not good •  Details are in the paper 12 Updated algorithm Idea: reduce the rate on conges,on as one flow. •  No conges,on: increase the aggregate by I/N where I is the increase factor. •  Conges,on: Propor,onally reduce the rate to emulate the conges,on response of one flow. –  Avoid over-­‐reac,ng: set a ,me (2RTTs) to react only once in the same loss event. 13 Some simula,on results F1 F1 F2 F2 Fn •
•
•
•
R1 R2 Fn Implemented in ns-­‐2 Two rate based protocols: –  Rate Adapta,on Protocol (RAP) –  TCP Friendly Transport Protocol (TFRC) BoUleneck – 10 Mbps, Queue-­‐length – 62 Packets (1/2 BDP), Packet Size – 1000 Bytes, RTT – 100 ms All tests (except when x-­‐axis = ,me) ran for 300 seconds, carried out 10 ,mes with random start ,mes picked from first second; stddev consistently very small ( <= 0.2% ) 14 Evalua,on – priori,za,on and fairness Fairness Priori@za@on Flow 1
Flow 2
8
6
0.8
0.6
2 Flows 0.4
0.2
0
4
FSE
Without FSE
5:1
10:1
15:1
20:1
RTT Ratio
2
0
1
0
50
100
150
200
250
300
Time(s)
Priority of flow 1 increased over ,me Fairness Index
Sending Rate (Mbps)
10
Fairness Index
1
0.8
5 Flows 0.6
0.4
0.2
0
1:1:1:1:1
FSE
Without FSE
16:8:4:2:1
32:16:8:4:2
RTT Ratio
48:24:12:6:3 15 Evalua,on – FSE controlled flows compe,ng with synthe,c traffic Goodput (Mbps)
•  TMIX synthe,c traffic, taken from 60 minute trace of campus traffic at the University of Carolina [TCP Evalua,on suite] •  We used the pre-­‐
processed version of this traffic which is adapted to provide an approximate load of 50% 6
Flow #1
Flow #2
5
4
3
2
1
0
1
0.9
0.8
0.7
0.6
0.5
0.4
0.3
0.2
0.1
Priority of Flow #2
16 25
Average Queue 20
15
FSE
Without FSE
2
11
10
9
8
7
6
5
4
3
2
1
0
4
6
8
10
12
14
16
18
# of Flows
6
8
10
12
Packet Loss Ra,o 14
16
18
Link U,liza,on 70
FSE
Without FSE
Throughput - 1 flow
4
6
8
10
12
# of Flows
35
FSE
Without FSE
4
6
8
10
12
14
16
18
20
# of Flows
1
0.5
FSE
Without FSE
2
4
6
8
100
80
2
40
0
20
90
50
45
2
2.5
# of Flows
60
50
Receiver makes assump,ons about 2 length of loss sending rate (expected interval) è loss event ra,o p calcula,on 1.5
wrong è sender too aggressive FSE
Without FSE
4
55
30
20
Packet Loss Ratio %
10
2
100
Link Utilization %
TFRC Average Queue Length
RAP 30
5
Packet Loss Ratio %
60
14
16
18
20
Link Utilization %
Average Queue Length
35
10
12
14
16
18
20
# of Flows
90
80
70
60
50
FSE
Without FSE
2
4
6
8
10
12
# of Flows
14
16
18
17 20
Different max Queue Lengths 70
65
60
55
50
45
40
35
30
25
20
15
60
TFRC 180
10 Flows FSE
Without FSE
80
100
120
140
160
Average Queue Length
Average Queue Length
RAP 160
140
120
100
80
60
20
60
180
FSE
Without FSE
40
80
100
Queue Length
160
180
180
80
70
15 Flows 60
50
40
30
FSE
Without FSE
80
100
120
140
Queue Length
160
180
Average Queue Length
Average Queue Length
140
Queue Length
90
20
60
120
160
140
120
100
80
60
FSE
Without FSE
40
20
60
80
100
120
140
Queue Length
160
18 180
How to evaluate app-­‐limited flows? •  Not easy: who is in control? •  RMCAT codec model not available yet •  From a transport point of view, the send buffer can either run empty or not, with varia,ons in how quickly changes between these two states occur –  We used a non-­‐reac,ng video trace of a person talking in a video conference with a well-­‐known H264 encoder (X264) to steer the app sending rate •  I-­‐frame in the beginning, rest was mostly P-­‐frames 19 Evalua,on – an applica,on limited flow and one greedy flow (RAP) FSE Without FSE 16
14
12
10
8
6
4
Flow 1
Flow 2
2
0
0
5
10
15
Time (s)
20
25
Sending Rate (Mbps)
Sending Rate (Mbps)
16
14
12
10
8
6
4
Flow 1
Flow 2
2
0
0
5
10
15
20
25
Time (s)
FSE-­‐controlled flows propor,onally reduce the rate in case of conges,on; without FSE, synchroniza,on causes app-­‐limited flow to over-­‐react 20 Using priori,es to “protect” the app-­‐
limited from the greedy flow (RAP) 25
Flow #1
Flow #2
Link Utilization
Throughput
20
15
10
5
0
40
35
30
25
20
15
10
5
Capacity
High-­‐priority (1) applica,on limited flow #1 is hardly affected by a low-­‐
priority (0.2) flow #2 as long as there is enough capacity for flow 1 21 Summary •  Coupled conges,on control via Flow State Exchange –  Currently proposed for WebRTC in the RMCAT group –  Sa,sfies the requirements of controllable fairness with priori,za,on –  Reduces queue delay and packet loss without significantly affec,ng throughput •  Future work –  Test our method in Chromium (Google’s CC) –  To incorporate WebRTC’s data channel, we will inves,gate coupling with window-­‐based protocol too 22 That’s all !! Ques@ons? 23 Backup slides 24 Experimental setup (simple algorithm) F1 F1 F2 F2 Fn R1 R2 BoUleneck -­‐ 10 Mbps Queue-­‐length – 13 Packets (1 BDP) Packet Size – 1000 Bytes Senders have always data to send Fn 25 Results – simple algorithm TFRC RAP 11
11
10
9
Average Queue Length 8
7
6
5
FSE
Without FSE
2
4
6
8
10
12
14
16
18
Average Queue Length
Average Queue Length
12
20
10.5
10
9.5
9
8.5
8
7.5
Number of Flows
FSE
Without FSE
2
4
6
8
10
12
14
16
18
20
Number of Flows
35
Packet Loss Ra,o 30
25
20
15
FSE
Without FSE
10
2
4
6
8
10
12
14
Number of Flows
16
18
20
Packet Loss Ratio %
Packet Loss Ratio %
40
5
Why? 14
45
12
10
8
6
4
2
0
FSE
Without FSE
2
4
6
8
10
12
14
16
18
20
Number of Flows
26 14
14
12
12
10
10
Queue size (pkts)
Queue size (pkts)
What’s going on? (simple algorithm) 8
6
8
6
4
4
2
2
0
0
15
15.5
16
16.5
17
17.5
18
18.5
19
15
15.5
16
16.5
Time (s)
With FSE 17
17.5
18
18.5
Time (s)
Without FSE •  Queue drains more oten without FSE –  Should emulate the conges,on response of one flow •  FSE: 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 halves the aggregate rate •  We want that ! 2X è 1X 27 19