Coupled Conges,on Control for RTP Media Safiqul Islam, - - PowerPoint PPT Presentation

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 ¡

Flow 1 Flow 2 Flow 3 Flow n

CC ¡ CC ¡ CC ¡

Each ¡Flow ¡has ¡its ¡own ¡Conges@on ¡ Control ¡module ¡

Compe,,on ¡ leads ¡to: ¡

• M
• r

e ¡ q u e u e ¡ g r

• w

t h ¡

• M
• r

e ¡ p a c k e t ¡ d r

• p

s ¡

• M
• r

e ¡ d e l a y ¡

• F

a i r n e s s ¡ p r

• b

l e m s ¡ i n ¡ c a s e ¡

• f

¡ h e t e r

• g

e n e

• u

s ¡ R T T s ¡

2 ¡

Problem ¡statement ¡– ¡cont. ¡

Flow 1 Flow 2 Flow 3 Flow n

CC ¡ CC ¡ CC ¡ Single ¡ Conges,on ¡ Controller ¡ 3 ¡

Coupled ¡CC ¡– ¡related ¡work ¡

Flow 1 Flow 2 Flow 3 Flow n

CC ¡ CC ¡ CC ¡ Single ¡ Conges,on ¡ Controller ¡

Conges,on ¡ Manager ¡– ¡ RFC ¡3124 ¡

Ensemble ¡TCP ¡-­‑ ¡ ETCP ¡ Ensemble ¡Flow ¡ Conges,on ¡ Management ¡

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. ¡ ¡

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 Flow 2 Flow 3 Flow n

Single ¡ Conges,on ¡ Controller ¡

This ¡might ¡work ¡well ¡for ¡ flows ¡having ¡same ¡tuple ¡but ¡ what ¡happens ¡when ¡ boUleneck ¡changes? ¡

6 ¡

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 ¡

Coupled ¡CC ¡

Flow 1 Flow 2 Flow 3 Flow n

CC ¡ CC ¡ CC ¡ Flow ¡State ¡ Exchange ¡(FSE) ¡ 8 ¡

The ¡Flow ¡State ¡Exchange ¡(FSE) ¡

FSE ¡ Shared ¡ BoUleneck ¡ Detec,on ¡ (SBD) ¡ Flow ¡1 ¡cc ¡ Flow ¡2 ¡cc ¡ Flow ¡3 ¡cc ¡ Flow ¡n ¡cc ¡

Sender ¡Host ¡ ¡

9 ¡

The ¡Flow ¡State ¡Exchange ¡(FSE) ¡

FSE ¡ Flow ¡1 ¡cc ¡ Flow ¡2 ¡cc ¡ Flow ¡n ¡cc ¡ Store ¡Informa,on ¡ Calculate ¡Rate ¡

¡Update_Rate ¡() ¡ New_Rate ¡

Sender ¡Host ¡ ¡

10 ¡

The ¡Flow ¡State ¡Exchange ¡(FSE) ¡

FSE ¡ Flow ¡1 ¡cc ¡ Flow ¡2 ¡cc ¡ Flow ¡n ¡cc ¡ Store ¡Informa,on ¡ Calculate ¡Rate ¡

¡Update_Rate ¡() ¡ New_Rate ¡

Sender ¡Host ¡ ¡

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 ¡

• Results ¡were ¡not ¡good ¡
• Details ¡are ¡in ¡the ¡paper ¡

for ¡all ¡flows ¡i ¡in ¡FG ¡do ¡ ¡FSE_R(i) ¡= ¡(P(i)*ΣCR)/ΣP ¡ ¡send ¡FSE_R(i) ¡to ¡the ¡flow ¡I ¡ end ¡for ¡

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 ¡

• nly ¡once ¡in ¡the ¡same ¡loss ¡event. ¡

13 ¡

Some ¡simula,on ¡results ¡

• 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 ¡

F1 ¡ F2 ¡ Fn ¡

R1 ¡ R2 ¡

F1 ¡ F2 ¡ Fn ¡

Evalua,on ¡– ¡priori,za,on ¡and ¡fairness ¡ ¡

2 4 6 8 10 50 100 150 200 250 300

Sending Rate (Mbps) Time(s) Flow 1 Flow 2

Priority ¡of ¡flow ¡1 ¡increased ¡over ¡ ,me ¡

0.2 0.4 0.6 0.8 1 5:1 10:1 15:1 20:1

Fairness Index RTT Ratio FSE Without FSE

0.2 0.4 0.6 0.8 1 1:1:1:1:1 16:8:4:2:1 32:16:8:4:2 48:24:12:6:3

Fairness Index RTT Ratio FSE Without FSE

Priori@za@on ¡ ¡ Fairness ¡

2 ¡Flows ¡ 5 ¡Flows ¡

15 ¡

Evalua,on ¡– ¡FSE ¡controlled ¡flows ¡ compe,ng ¡with ¡synthe,c ¡traffic ¡

1 2 3 4 5 6 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

Goodput (Mbps) Priority of Flow #2 Flow #1 Flow #2

• 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 ¡

• f ¡50% ¡

16 ¡

5 10 15 20 25 30 35 2 4 6 8 10 12 14 16 18 20

Average Queue Length # of Flows FSE Without FSE

30 35 40 45 50 55 60 2 4 6 8 10 12 14 16 18 20

Average Queue Length # of Flows FSE Without FSE

1 2 3 4 5 6 7 8 9 10 11 2 4 6 8 10 12 14 16 18 20

Packet Loss Ratio % # of Flows FSE Without FSE

0.5 1 1.5 2 2.5 2 4 6 8 10 12 14 16 18 20

Packet Loss Ratio % # of Flows FSE Without FSE

RAP ¡ TFRC ¡ Average ¡ Queue ¡ Packet ¡ Loss ¡ Ra,o ¡

Receiver ¡makes ¡assump,ons ¡about ¡ sending ¡rate ¡(expected ¡length ¡of ¡loss ¡ interval) ¡è ¡loss ¡event ¡ra,o ¡p ¡calcula,on ¡ wrong ¡è ¡sender ¡too ¡aggressive ¡

50 60 70 80 90 100 2 4 6 8 10 12 14 16 18 20

Link Utilization % # of Flows FSE Without FSE Throughput - 1 flow

50 60 70 80 90 100 2 4 6 8 10 12 14 16 18 20

Link Utilization % # of Flows FSE Without FSE

Link ¡ U,liza,on ¡

17 ¡

Different ¡max ¡Queue ¡Lengths ¡ ¡ ¡

15 20 25 30 35 40 45 50 55 60 65 70 60 80 100 120 140 160 180

Average Queue Length Queue Length FSE Without FSE

RAP ¡ TFRC ¡

20 30 40 50 60 70 80 90 60 80 100 120 140 160 180

Average Queue Length Queue Length FSE Without FSE

10 ¡Flows ¡ 15 ¡Flows ¡

20 40 60 80 100 120 140 160 180 60 80 100 120 140 160 180

Average Queue Length Queue Length FSE Without FSE

20 40 60 80 100 120 140 160 180 60 80 100 120 140 160 180

Average Queue Length Queue Length FSE Without FSE 18 ¡

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) ¡

2 4 6 8 10 12 14 16 5 10 15 20 25

Sending Rate (Mbps) Time (s) Flow 1 Flow 2

2 4 6 8 10 12 14 16 5 10 15 20 25

Sending Rate (Mbps) Time (s) Flow 1 Flow 2

FSE ¡ Without ¡FSE ¡ 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) ¡

5 10 15 20 25 5 10 15 20 25 30 35 40

Throughput Capacity Flow #1 Flow #2 Link Utilization

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 ¡ F2 ¡ Fn ¡

R1 ¡ R2 ¡

F1 ¡ F2 ¡ Fn ¡

BoUleneck ¡-­‑ ¡10 ¡Mbps ¡ Queue-­‑length ¡– ¡13 ¡Packets ¡(1 ¡BDP) ¡ Packet ¡Size ¡– ¡1000 ¡Bytes ¡ Senders ¡have ¡always ¡data ¡to ¡send ¡ ¡

25 ¡

Results ¡– ¡simple ¡algorithm ¡

5 6 7 8 9 10 11 12 2 4 6 8 10 12 14 16 18 20

Average Queue Length Number of Flows FSE Without FSE

RAP ¡ TFRC ¡ Average ¡ Queue ¡ Length ¡

7.5 8 8.5 9 9.5 10 10.5 11 2 4 6 8 10 12 14 16 18 20

Average Queue Length Number of Flows FSE Without FSE

5 10 15 20 25 30 35 40 45 2 4 6 8 10 12 14 16 18 20

Packet Loss Ratio % Number of Flows FSE Without FSE

2 4 6 8 10 12 14 2 4 6 8 10 12 14 16 18 20

Packet Loss Ratio % Number of Flows FSE Without FSE

Packet ¡ Loss ¡ Ra,o ¡ Why? ¡

26 ¡

What’s ¡going ¡on? ¡(simple ¡algorithm) ¡

• 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 ¡

2 4 6 8 10 12 14 15 15.5 16 16.5 17 17.5 18 18.5 19 Queue size (pkts) Time (s) 2 4 6 8 10 12 14 15 15.5 16 16.5 17 17.5 18 18.5 19 Queue size (pkts) Time (s)

With ¡FSE ¡ Without ¡FSE ¡

27 ¡