Designing TCP-Friendly Window-based Congestion
Control for Real-time Multimedia Applications
PFLDNeT 2009
Soo-Hyun Choi an...
congestion control for
real-time multimedia applications
• Two key common demands
– Timely delivery over perfect reliabili...
problems and goals
• TFRC works incorrectly in certain circumstances
• Fairness
– It could starve TCP traffics at a DSL-li...
fairness
• DSL-like link (low statistical mux), Drop-tail queue
with a tiny bottleneck buffer
– TFRC is sufficiently smoot...
smoothness and practical issue
• Short-term oscillatory behaviour
– To avoid this:
• Original TFRC used for inter-packet s...
motivation (1/2)
Do we have to be rate-based to be smooth?
Is rate-based worth all the trouble?
motivation
• Problems with rate-based control
– Fairness
– Hard to implement
• Solution: Smooth Thruput with Ack-clocking
...
TCP-Friendly Window-based
Congestion Control (TFWC)
• Re-introduce TCP-like Ack-clock
– Using a window, it can embed RTT i...
window calculation
• Window calculation using TCP-equation
– From the original TCP-equation
– Multiply , then we get windo...
loss event rate
• Average Loss Interval
– Weighted average interval of packet losses
• Loss event rate from average loss i...
Ack Vector
• What is it?
– Data structure for Ack message
– No cumulative Ack numbers (unreliable transport)
• Data receiv...
Upon receipt of AckVec
• Sender determines which packets are missing:
TFWC mechanisms (4/9)
20 19 18 16 15 14 13 11 10
Lat...
sender functionality
• On every AckVec reception
– Check packet loss
– Compute Average Loss Interval
– Calculate cwnd usin...
hybrid window and rate (1/2)
• When the loss rate is high:
– A packet loss can cause timeout with very small windows due t...
hybrid window and rate (2/2)
– One TCP/TFRC/TFWC for the queue size of 5 packets
– 500 Kb/s with 50 ms delay of the bottle...
cwnd jitter (1/2)
• TFWC's throughput often less smooth enough for
interactive streaming applications than that of TFRC
– ...
cwnd jitter (2/2)
TFWC mechanisms (9/9)
Without jitter With jitter
FIFO
TFWC
Dest.8 TFWCs
5 Mb/s
50 ms
5 Mb/s
50 ms
50 Mb/...
Protocol Analysis
Friendliness, Smoothness, Responsiveness
analysis
TCP-Friendly (1/2)
• Scenario
– Varying # of sources from 1 to 100 in a dumbbell topology
– Varying bottleneck BW from 0.1...
TCP-Friendly (2/2)
analysis > fairness (2/2)
– For TFRC, Θ ~ 0.1 when bottleneck BW is low
– For TFWC, though it is not pe...
smoothness (1/4)
• Scenario
– Are we going to loose all the nice smoothness property by re-
introducing TCP-like Ack-clock...
smoothness (2/4)
analysis > smoothness (2/4)
– TFRC's CoV is very high (> 0.9) when # of sources is small
– TFWC's CoV is ...
smoothness – detailed (3/4)
• Scenario
– 8 TFR(W)C competing with the same # of TCP
– Bottleneck of 5 Mb/s with 20 ms link...
smoothness – detailed (4/4)
analysis > smoothness (4/4)
• TCP
• TFRC
• TFWC
responsiveness (1/2)
• Scenario
– Stress TCP/TFRC/TFWC with impulse response as a form
of ON/OFF CBR source
• CBR rate is ...
responsiveness (2/2)
analysis > responsiveness (2/2)
CBR On CBR Off
conclusion
• TFWC achieved providing:
1. Fairer throughput
2. Same level of smoothness with that of TFRC
3. Faster respons...
Upcoming SlideShare
Loading in …5
×

Designing TCP-Friendly Window-based Congestion Control

1,193 views
1,101 views

Published on

Designing TCP-Friendly Window-based Congestion Control for Real-time Multimedia Applications

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,193
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Designing TCP-Friendly Window-based Congestion Control

  1. 1. Designing TCP-Friendly Window-based Congestion Control for Real-time Multimedia Applications PFLDNeT 2009 Soo-Hyun Choi and Mark Handley University College London
  2. 2. congestion control for real-time multimedia applications • Two key common demands – Timely delivery over perfect reliability – Smooth and predictable throughput • Proposed standard: TFRC – What it solves? • Smooth and predictable throughput – How it solved? • Equation-based sending rate control by modelling TCP throughput background
  3. 3. problems and goals • TFRC works incorrectly in certain circumstances • Fairness – It could starve TCP traffics at a DSL-like link (especially with a very small bottleneck buffer) • Smoothness – It could generate unwanted throughput oscillation in a short-term timescale (due to EWMA coeff. when measuring RTT) • Hard to Implement – If RTT is smaller than CPU interrupt cycle, it will have to sub- sample it, which in turn leads a noise in throughput calculation problems and goals (1/3)
  4. 4. fairness • DSL-like link (low statistical mux), Drop-tail queue with a tiny bottleneck buffer – TFRC is sufficiently smooth due to the different fine-grain CC avoidance mechanism from TCP problems and goals (2/3) FIFO TCP TFRC Dest. 2 TCP and 2 TFRC Droptail (5 packets) Bottleneck link = 1Mb/s
  5. 5. smoothness and practical issue • Short-term oscillatory behaviour – To avoid this: • Original TFRC used for inter-packet spacing • Bansal introduced 'conservative' mode – Worked well in the simulations, but not so sure in real-world • Practical issue (uneasiness to implement correctly) – Saurin observed the regular TFRC cuts inappropriately when RTT is small (e.g., less than a host OS's interrupt clock granularity) problems and goals (3/3) RTT i E RTT s
  6. 6. motivation (1/2) Do we have to be rate-based to be smooth? Is rate-based worth all the trouble?
  7. 7. motivation • Problems with rate-based control – Fairness – Hard to implement • Solution: Smooth Thruput with Ack-clocking motivation (2/2) If there is another mean that can achieve better fairness and make easy to implement without compromising smoothness, then?
  8. 8. TCP-Friendly Window-based Congestion Control (TFWC) • Re-introduce TCP-like Ack-clock – Using a window, it can embed RTT implicit in the Ack-clock – No need to work around the OS's interrupt timer • Smoothness, Friendliness, Responsiveness – By using TCP-equation with the change to Ack-clock can retain “ Friendliness” and “ Responsiveness” property – Do we lose “ Smoothness” after all? proposal
  9. 9. window calculation • Window calculation using TCP-equation – From the original TCP-equation – Multiply , then we get window size: TFWC mechanisms (1/9) W = 1 2p 3 12 3p 8  p132p 2  tRTT /s T = s t RTT 2p 3 12 3p 8  p132p 2 
  10. 10. loss event rate • Average Loss Interval – Weighted average interval of packet losses • Loss event rate from average loss interval TFWC mechanisms (2/9) Loss Event Rate  p= 1 Average Loss Interval
  11. 11. Ack Vector • What is it? – Data structure for Ack message – No cumulative Ack numbers (unreliable transport) • Data receiver builds AckVec – Packet list indicating the packet has arrived – Data receiver sends in an acknowledgement • Data sender reports Ack of Ack (AoA) – Data receiver prune AckVec based upon AoA TFWC mechanisms (3/9)
  12. 12. Upon receipt of AckVec • Sender determines which packets are missing: TFWC mechanisms (4/9) 20 19 18 16 15 14 13 11 10 Latest Ack AoA 19 18 17 16 15 14 13 12 11 margin to allow re-ordering packet loss Received AckVec
  13. 13. sender functionality • On every AckVec reception – Check packet loss – Compute Average Loss Interval – Calculate cwnd using the equation – Send the next available packets if: – Update RTT and RTO → Hence, making it sender driven Ack-clock basis TFWC mechanisms (5/9) ≤Seqno. of New Data cwnd + Unacked Seqno.
  14. 14. hybrid window and rate (1/2) • When the loss rate is high: – A packet loss can cause timeout with very small windows due to the Ack- clock failure – The equation can result in cwnd less than one, for example.: • when p > 0.15, then W < 1 • when p > 0.1, then W < 2 • TCP-like timeout method to clock packets out? – Constant switching between window and timeout??? – Some of them will do exponential back-off, too. → TFRC-like rate-based when window is so small (i.e., when cwnd is less than 2) TFWC mechanisms (6/9)
  15. 15. hybrid window and rate (2/2) – One TCP/TFRC/TFWC for the queue size of 5 packets – 500 Kb/s with 50 ms delay of the bottleneck link – This is a boarder-line case where it doesn't run rate-driven always. TFWC mechanisms (7/9) Window only mode Hybrid mode
  16. 16. cwnd jitter (1/2) • TFWC's throughput often less smooth enough for interactive streaming applications than that of TFRC – Phase effect? • Maybe, yes, as flows through same bottleneck show different loss rate. – This can be significantly mitigated by RED queue • Being motivated by RED, – Randomly add cwnd 'jitter' by inflating cwnd at least once an RTT – Borrow a “ future” packet that would have been sent in that RTT • Results: – Reverses packet phase, hence breaking phase effects TFWC mechanisms (8/9)
  17. 17. cwnd jitter (2/2) TFWC mechanisms (9/9) Without jitter With jitter FIFO TFWC Dest.8 TFWCs 5 Mb/s 50 ms 5 Mb/s 50 ms 50 Mb/s BDP = 63 Drop-tail Size = BDP
  18. 18. Protocol Analysis Friendliness, Smoothness, Responsiveness analysis
  19. 19. TCP-Friendly (1/2) • Scenario – Varying # of sources from 1 to 100 in a dumbbell topology – Varying bottleneck BW from 0.1 ~ 20 Mb/s with 10ms delay – Reverse path TCP sources to reveal issues about Ack- compression and reduce phase effect – Drop-tail queue with a size of BDP • Fairness Index (Θ) = analysis > fairness (1/2) ∑ i =1 n T tcpi ∑i=1 n T tcpi ∑j =1 n T j
  20. 20. TCP-Friendly (2/2) analysis > fairness (2/2) – For TFRC, Θ ~ 0.1 when bottleneck BW is low – For TFWC, though it is not perfect, it certainly does a lot better than TFRC TCP competing with the same number of TFRC TCP competing with the same number of TFWC
  21. 21. smoothness (1/4) • Scenario – Are we going to loose all the nice smoothness property by re- introducing TCP-like Ack-clock? • Let's plot Coefficient of Variance (CoV). – Same simulation sets used in fairness comparison cases, and plot averaged per-flow CoVs CoV = analysis > smoothness (1/4) 1 k ∑ i=1 k Ti − T 2 T : average throughput over time k : number of time intervals (time interval = 0.5 sec) T
  22. 22. smoothness (2/4) analysis > smoothness (2/4) – TFRC's CoV is very high (> 0.9) when # of sources is small – TFWC's CoV is relatively high when bottleneck BW is small TFRC CoV TFWC CoV
  23. 23. smoothness – detailed (3/4) • Scenario – 8 TFR(W)C competing with the same # of TCP – Bottleneck of 5 Mb/s with 20 ms link delay, Drop-tail queue with a size of 300 packets – Average cwnd per flow = – Reverse path TCP sources: • To reduce simulation phase effect • To perturb the TFWC Ack flow analysis > smoothness (3/4) BDPqueuesize no.of TCPno of TFWC ≈15 packets
  24. 24. smoothness – detailed (4/4) analysis > smoothness (4/4) • TCP • TFRC • TFWC
  25. 25. responsiveness (1/2) • Scenario – Stress TCP/TFRC/TFWC with impulse response as a form of ON/OFF CBR source • CBR rate is the half of the links speed – Bottleneck of 1.5 Mb/s with roughly 60 ms of RTT – Drop-tail queue with arbitrary large queue size – One CBR source competing with one TFR(W)C analysis > responsiveness (1/2)
  26. 26. responsiveness (2/2) analysis > responsiveness (2/2) CBR On CBR Off
  27. 27. conclusion • TFWC achieved providing: 1. Fairer throughput 2. Same level of smoothness with that of TFRC 3. Faster responsiveness 4. Simpler to implement without bearing all the trouble that a rate-based CC has. • Future work – Question on what is really better for such an application between a rate-based CC and a window-based CC. – Move to the real-world experiments conclusion

×