Coupled Conges,on Control for RTP Media. Safiqul Islam, Michael Welzl, Stein Gjessing and Naeem Khademi Department of Informa,cs University of Oslo

Transcription

1 Coupled Conges,on Control for RTP Media Safiqul Islam, Michael Welzl, Stein Gjessing and Naeem Khademi Department of Informa,cs University of Oslo

2 Problem statement Each Flow has its own Control module Flow 1! CC Flow 2! CC Flow 3! CC Compe,,on leads to: Flow n! More queue growth More packet drops More delay Fairness problems in case of heterogeneous RTTs 2

3 Problem statement cont. Flow 1! CC Single Conges,on Controller Flow 2! CC Flow 3! CC Flow n! 3

4 Coupled CC related work Flow 1! Flow 2! Flow 3! Flow n! CC CC CC Single Conges,on Controller Best known, perhaps the oldest related work. Hard to implement: Provides a common conges,on framework 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 4

5 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 0% 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

6 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

7 Coupled CC Flow 1! Flow 2! Flow 3! Flow n! 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. 7

8 Coupled CC Flow 1! CC Flow State Exchange () Flow 2! CC Flow 3! CC Flow n! 8

9 The Flow State Exchange () Sender Host Flow 1 cc Flow 2 cc Flow 3 cc Shared BoUleneck Detec,on (SBD) Flow n cc 9

10 The Flow State Exchange () Sender Host Store Informa,on Calculate Rate Update_Rate () New_Rate Flow 1 cc Flow 2 cc Flow n cc

11 The Flow State Exchange () Sender Host Store Informa,on Flow 1 cc Calculate Rate Update_Rate () New_Rate Flow 2 cc Flow n cc 11

12 Simple algorithm Every,me the conges,on controller of a flow determines a new sending rate, the flow calls UPDATE updates the sum of all rates, calculates the sending rates for all the flows and distributes them Results were not good Details are in the paper for all flows i in FG do _R(i) = (P(i)*ΣCR)/ΣP send _R(i) to the flow I end for 12

13 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

14 Some simula,on results F1 F1 F2 R1 R2 F2 Fn Fn Implemented in ns- 2 Two rate based protocols: Rate Adapta,on Protocol (RAP) TCP Friendly Transport Protocol (TFRC) BoUleneck Mbps, Queue- length 62 Packets (1/2 BDP), Packet Size 00 Bytes, RTT 0 ms All tests (except when x- axis =,me) ran for 300 seconds, carried out,mes with random start,mes picked from first second; stddev consistently very small ( <= 0.2% ) 14

15 Evalua,on priori,za,on and fairness Sending Rate (Mbps) Priori@za@on Flow 1 Flow Time(s) Priority of flow 1 increased over,me Fairness Fairness Index Fairness Index :1 :1 15:1 20:1 RTT Ratio Without 0 1:1:1:1:1 16:8:4:2:1 32:16:8:4:2 48:24:12:6:3 RTT Ratio Without 2 Flows 5 Flows 15

16 Evalua,on controlled flows compe,ng with synthe,c traffic 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% Goodput (Mbps) Flow #1 Flow # Priority of Flow #

17 Packet Loss Ratio % Average Queue Length # of Flows Without # of Flows Without RAP Average Queue Average Queue Length sending rate (expected 2 length of loss Packet Loss Ra,o TFRC Packet Loss Ratio % Receiver makes assump,ons about # of Flows interval) è loss event ra,o p calcula,on 1.5 wrong è sender too aggressive 0 Without # of Flows Without Link Utilization % Without Throughput - 1 flow # of Flows Link U,liza,on Link Utilization % # of Flows Without 17

18 Different max Queue Lengths RAP Average Queue Length Queue Length Without Flows Average Queue Length TFRC Queue Length Without Average Queue Length Queue Length Without 15 Flows Average Queue Length Queue Length Without

19 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

20 Sending Rate (Mbps) Evalua,on an applica,on limited flow and one greedy flow (RAP) Time (s) Sending Rate (Mbps) Flow 1 2 Flow Without Time (s) Flow 1 Flow 2 - controlled flows propor,onally reduce the rate in case of conges,on; without, synchroniza,on causes app- limited flow to over- react 20

21 Using priori,es to protect the app- limited from the greedy flow (RAP) Flow #1 Flow #2 Link Utilization Throughput Capacity 15 5 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

22 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

23 That s all!! Ques@ons? 23

24 Backup slides 24

25 Experimental setup (simple algorithm) F1 F1 F2 R1 R2 F2 Fn BoUleneck - Mbps Queue- length 13 Packets (1 BDP) Packet Size 00 Bytes Senders have always data to send Fn 25

26 Results simple algorithm RAP TFRC Average Queue Length Number of Flows Without Average Queue Length Average Queue Length Number of Flows Without Why? Packet Loss Ratio % Number of Flows Without Packet Loss Ra,o Packet Loss Ratio % Number of Flows Without 26

27 What s going on? (simple algorithm) Queue size (pkts) 8 6 Queue size (pkts) Time (s) Time (s) With Without Queue drains more oten without Should emulate the conges,on response of one flow : 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