Your SlideShare is downloading. ×
Designing TCP-Friendly Window-based Congestion Control
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Designing TCP-Friendly Window-based Congestion Control

993
views

Published on

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

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
993
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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. 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. 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. 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. 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. motivation (1/2) Do we have to be rate-based to be smooth? Is rate-based worth all the trouble?
  • 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Protocol Analysis Friendliness, Smoothness, Responsiveness analysis
  • 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. 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. 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. 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. 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. smoothness – detailed (4/4) analysis > smoothness (4/4) • TCP • TFRC • TFWC
  • 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. responsiveness (2/2) analysis > responsiveness (2/2) CBR On CBR Off
  • 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