1 / 23

TCP Friendly Streaming

TCP Friendly Streaming. Ketan Mayer-Patel. TCP Congestion Control Review. 3 phases Slow-start Probing for initial congestion level. Congestion Avoidance Additive increase, multiplicative decrease Fast Retransmission/Recovery Optimizations. Slow-Start. At beginning or after an RTO loss.

parson
Download Presentation

TCP Friendly Streaming

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. TCP Friendly Streaming Ketan Mayer-Patel CS 294-9 :: Fall 2003

  2. TCP Congestion Control Review • 3 phases • Slow-start • Probing for initial congestion level. • Congestion Avoidance • Additive increase, multiplicative decrease • Fast Retransmission/Recovery • Optimizations CS 294-9 :: Fall 2003

  3. Slow-Start • At beginning or after an RTO loss. • Window set to 1 segment. • Every new ACK grows window by 1. • If ssthresh not yet set: • Keep going until RTO loss occurs. • Set ssthresh to 1/2 window size. • Start over. • If ssthresh set, transition to avoidance phase. CS 294-9 :: Fall 2003

  4. Congestion Avoidance • Grow window by 1/window for every ACK. • When RTO loss occurs: • Set ssthresh to half window size. • Set window to 1. • Go back to slow start. CS 294-9 :: Fall 2003

  5. Fast Retransmit/Recover • If three duplicate ACK’s detected: • Retransmit segment identified by duplicate ACK’s. • Set ssthresh to 1/2 window size. • Set window size to ssthresh. • As long as dup acks keep coming, use the following window size equation: • window + # dup acks • If ack changes, go back to avoidance. • If RTO occurs, back to slow start. CS 294-9 :: Fall 2003

  6. AIMD Graphically • TCP congestion control mostly modeled as being in AIMD phase in steady-state. Window Size ssthresh Time CS 294-9 :: Fall 2003

  7. Steady State Control Laws • Increase: wt+R = wt + a • Decrease wt+R = wt *b CS 294-9 :: Fall 2003

  8. AIMD Fairness • AIMD motivated by fairness and stability. • Claim is that AIMD will push multiple TCP connections into a fair and stable operating point. • Formally unproven, but can provide intuition graphically. CS 294-9 :: Fall 2003

  9. AIMD Fairness Graphically Window Size of A Window Size of B CS 294-9 :: Fall 2003

  10. AIMD Fairness Problems • What assumptions are made by the graphical “proof” • Synchronous reaction by both participants. • What governs when TCP reacts? • Round-trip time. • Thus, longer RTT connections might lose to shorter RTT connections. CS 294-9 :: Fall 2003

  11. Loss as Congestion • TCP congestion control couples loss with congestion. • Every loss is a congestion event. • Where does loss come from? • Overflowing queues in bottleneck routers. • Rarely from network level congestion. CS 294-9 :: Fall 2003

  12. RED • Random Early Drop • Introduced as a way of providing congestion feedback before queues completely full. • Basic operation: • Router keeps track of weighted average queue length. • Below some low threshold, nothing done. • Between low and high thresholds, probability of dropping increases linearly • Above high threshold, everything dropped. CS 294-9 :: Fall 2003

  13. Forced drop Maxthreshold Probabilisticearly drop Minthreshold No drop Initial drop probability 100% maxp Weighted Average Queue Length minth maxth RED Graphically Instantaneous queue length Maxqueue length Time CS 294-9 :: Fall 2003

  14. ECN • Explicit Congestion Notification • Instead of dropping packet, mark it. • Receiver echoes the mark back to sender in the next ACK (and all ACK’s thereafter). • Sender clears the mark after it makes adjustment. • Recent evidence that shows that ECN essential for any active queue management scheme. CS 294-9 :: Fall 2003

  15. MM Streams and TCP • Congestion control only works if everyone plays along. • Unrestricted datagram traffic will clobber TCP. • Clearly, need congestion control, but in what form. CS 294-9 :: Fall 2003

  16. Why not TCP? • Could just use TCP without the reliability part. Why might this be problematic? • Large, sudden changes in rate. • Caused by slow start, RTO’s, etc. CS 294-9 :: Fall 2003

  17. TCP Friendliness • To avoid being labeled “unreactive”, we need to “look” like TCP. • Two basic strategies: • Use a “TCP-compatible” congestion control algorithm to determing sending rate. • Use encoding and streaming strategies that can deal with rapid rate changes induced by TCP. • Combine these together. CS 294-9 :: Fall 2003

  18. TCP-Compatible Cong. Control • What’s the right metric for compatibility? • A control algorithm is TCP-compatible (or friendly) if it achieves the same long-term throughput as TCP given similar network conditions. CS 294-9 :: Fall 2003

  19. Analyzing TCP B = # packets * S / #RTT * RTT Want an expression for bandwidth of connection in terms of loss and delay. # packets = 3/2 n2 B = (3/2 n*S) / RTT Loss probability = L Expected loss = 1 2 * ssthresh Window Size (# Segments) # packets such that E(loss) = 1 given L is 1/L ssthresh n = sqrt(2/(3L)) n B = sqrt(3/(2L))*S/RTT Time (# RTT’s) CS 294-9 :: Fall 2003

  20. RAP • Rate-based version of TCP AIMD • Periodically probe for greater bandwidth • No more than once per RTT • Immediately react to congestion. • AIMD applied to inter-packet gap • No longer need to maintain a “window” • Presumes constant packet sizes • Appropriate constants provide TCP-friendliness • Coupled with fine-grained adaptation • This is key. • Will see more about this in the papers. CS 294-9 :: Fall 2003

  21. Binomial Congestion Control • Bansal and Balakrishnan, 2001 • Non-linear congestion control law. • Parameterized by k and l • AIMD is simply one point in parameter space. • Control laws: • wt+R = wt + a / wtk • wt+R = wt - b * wtl • When k = 0, and l = 1, reduces to AIMD • Other parameter choices proven to be TCP-compatible but generate smoother rate changes. CS 294-9 :: Fall 2003

  22. Rate-based Congestion Control • Previous analysis of TCP congestion control is naïve. • Padhye et al. Provide a better analysis. • Basic idea: • Keep measures of RTT and loss and modulate rate in accordance to TCP analysis. • TCP Vegas proposes to do this with TCP itself. CS 294-9 :: Fall 2003

  23. TFRC • Motivation • TCP-friendly congestion control without sudden rate changes. • Equation-based • Estimates loss and RTT and plugs them directly into analytical estimate for TCP throughput • Estimating loss • Loss “event” as opposed to pure loss • Want to avoid counting more than one loss per RTT • Loss even interval = # of packets between loss events. • Loss rate is weighted average of last 10 loss event intervals. CS 294-9 :: Fall 2003

More Related