Queueing theory for TCP Damon Wischik, UCL Gaurav Raina, Cambridge.

Slides:



Advertisements
Similar presentations
Helping TCP Work at Gbps Cheng Jin the FAST project at Caltech
Advertisements

Michele Pagano – A Survey on TCP Performance Evaluation and Modeling 1 Department of Information Engineering University of Pisa Network Telecomunication.
Restless bandits and congestion control Mark Handley, Costin Raiciu, Damon Wischik UCL.
Queueing theory and Internet congestion control Damon Wischik, UCL Mark Handley, UCL Gaurav Raina, Cambridge / IIT Madras.
Doc.: IEEE /0604r1 Submission May 2014 Slide 1 Modeling and Evaluating Variable Bit rate Video Steaming for ax Date: Authors:
Congestion Control Created by M Bateman, A Ruddle & C Allison As part of the TCP View project.
Congestion Control: TCP & DC-TCP Swarun Kumar With Slides From: Prof. Katabi, Alizadeh et al.
CS 268: Lecture 7 (Beyond TCP Congestion Control) Ion Stoica Computer Science Division Department of Electrical Engineering and Computer Sciences University.
Restricted Slow-Start for TCP William Allcock 1,2, Sanjay Hegde 3 and Rajkumar Kettimuthu 1,2 1 Argonne National Laboratory 2 The University of Chicago.
Mathematical models of the Internet Frank Kelly Hood Fellowship Public Lecture University of Auckland 3 April 2012.
Router-assisted congestion control Lecture 8 CS 653, Fall 2010.
Advanced Computer Networking Congestion Control for High Bandwidth-Delay Product Environments (XCP Algorithm) 1.
XCP: Congestion Control for High Bandwidth-Delay Product Network Dina Katabi, Mark Handley and Charlie Rohrs Presented by Ao-Jan Su.
TCP Stability and Resource Allocation: Part II. Issues with TCP Round-trip bias Instability under large bandwidth-delay product Transient performance.
Fair queueing and congestion control Jim Roberts (France Telecom) Joint work with Jordan Augé Workshop on Congestion Control Hamilton Institute, Sept 2005.
On Modeling Feedback Congestion Control Mechanism of TCP using Fluid Flow Approximation and Queuing Theory  Hisamatu Hiroyuki Department of Infomatics.
TDC365 Spring 2001John Kristoff - DePaul University1 Internetworking Technologies Transmission Control Protocol (TCP)
Congestion Control Tanenbaum 5.3, /12/2015Congestion Control (A Loss Based Technique: TCP)2 What? Why? Congestion occurs when –there is no reservation.
AQM for Congestion Control1 A Study of Active Queue Management for Congestion Control Victor Firoiu Marty Borden.
TCP Stability and Resource Allocation: Part I. References The Mathematics of Internet Congestion Control, Birkhauser, The web pages of –Kelly, Vinnicombe,
High speed TCP’s. Why high-speed TCP? Suppose that the bottleneck bandwidth is 10Gbps and RTT = 200ms. Bandwidth delay product is packets (1500.
Sizing Router Buffers Nick McKeown Guido Appenzeller & Isaac Keslassy SNRC Review May 27 th, 2004.
Modeling TCP in Small-Buffer Networks
ACN: AVQ1 Analysis and Design of an Adaptive Virtual Queue (AVQ) Algorithm for Active Queue Managment Srisankar Kunniyur and R. Srikant SIGCOMM’01 San.
Estimating Congestion in TCP Traffic Stephan Bohacek and Boris Rozovskii University of Southern California Objective: Develop stochastic model of TCP Necessary.
Congestion Control for High Bandwidth-Delay Product Environments Dina Katabi Mark Handley Charlie Rohrs.
1 A State Feedback Control Approach to Stabilizing Queues for ECN- Enabled TCP Connections Yuan Gao and Jennifer Hou IEEE INFOCOM 2003, San Francisco,
Buffer requirements for TCP: queueing theory & synchronization analysis Gaurav RainaDamon Wischik CambridgeUCL.
New Designs for the Internet Why can’t I get higher throughput? Why is my online video jerky? How is capacity shared in the Internet?
Buffer requirements for TCP Damon Wischik DARPA grant W911NF
The teleology of Internet congestion control Damon Wischik, Computer Science, UCL.
CS144 An Introduction to Computer Networks
Queueing analysis of a feedback- controlled (TCP/IP) network Gaurav RainaDamon WischikMark Handley CambridgeUCLUCL.
Congestion models for bursty TCP traffic Damon Wischik + Mark Handley University College London DARPA grant W911NF
CS540/TE630 Computer Network Architecture Spring 2009 Tu/Th 10:30am-Noon Sue Moon.
Queueing theory for TCP Damon Wischik University College London TexPoint fonts used in EMF. Read the TexPoint manual before you delete this box.: A A.
27th, Nov 2001 GLOBECOM /16 Analysis of Dynamic Behaviors of Many TCP Connections Sharing Tail-Drop / RED Routers Go Hasegawa Osaka University, Japan.
Congestion Control for High Bandwidth-Delay Product Networks D. Katabi (MIT), M. Handley (UCL), C. Rohrs (MIT) – SIGCOMM’02 Presented by Cheng.
TCP with Variance Control for Multihop IEEE Wireless Networks Jiwei Chen, Mario Gerla, Yeng-zhong Lee.
CS640: Introduction to Computer Networks Aditya Akella Lecture 20 - Queuing and Basics of QoS.
1 TCP - Part II Relates to Lab 5. This is an extended module that covers TCP data transport, and flow control, congestion control, and error control in.
The history of the Internet 1974: First draft of TCP/IP “A protocol for packet network interconnection”, Vint Cerf and Robert Kahn 1983: ARPANET switches.
CS640: Introduction to Computer Networks Aditya Akella Lecture 15 TCP – III Reliability and Implementation Issues.
Computer Networking Lecture 18 – More TCP & Congestion Control.
1 CS 4396 Computer Networks Lab TCP – Part II. 2 Flow Control Congestion Control Retransmission Timeout TCP:
CS640: Introduction to Computer Networks Aditya Akella Lecture 15 TCP – III Reliability and Implementation Issues.
1 Time-scale Decomposition and Equivalent Rate Based Marking Yung Yi, Sanjay Shakkottai ECE Dept., UT Austin Supratim Deb.
New designs for Internet congestion control Damon Wischik (UCL)
1 TCP - Part II. 2 What is Flow/Congestion/Error Control ? Flow Control: Algorithms to prevent that the sender overruns the receiver with information.
Analysis of RED Goal: impact of RED on loss and delay of bursty (TCP) and less bursty or smooth (UDP) traffic RED eliminates loss bias against bursty traffic.
1 Computer Networks Congestion Avoidance. 2 Recall TCP Sliding Window Operation.
The Macroscopic behavior of the TCP Congestion Avoidance Algorithm.
Random Early Detection (RED) Router notifies source before congestion happens - just drop the packet (TCP will timeout and adjust its window) - could make.
TCP transfers over high latency/bandwidth networks & Grid DT Measurements session PFLDnet February 3- 4, 2003 CERN, Geneva, Switzerland Sylvain Ravot
XCP: eXplicit Control Protocol Dina Katabi MIT Lab for Computer Science
Queueing theory for TCP Damon Wischik, UCL Gaurav Raina, Cambridge.
Queueing theory, control theory, & buffer sizing Damon Wischik DARPA grant W911NF
TCP - Part II Relates to Lab 5. This is an extended module that covers TCP flow control, congestion control, and error control in TCP.
Topics discussed in this section:
Introduction to Congestion Control
Queue Dynamics with Window Flow Control
TCP - Part II Relates to Lab 5. This is an extended module that covers TCP flow control, congestion control, and error control in TCP.
Lecture 19 – TCP Performance
FAST TCP : From Theory to Experiments
CS640: Introduction to Computer Networks
Internet congestion control
TCP: Transmission Control Protocol Part II : Protocol Mechanisms
Modeling and Evaluating Variable Bit rate Video Steaming for ax
Gaurav Raina Damon Wischik Mark Handley Cambridge UCL UCL
Presentation transcript:

Queueing theory for TCP Damon Wischik, UCL Gaurav Raina, Cambridge

DJW /24 Some Internet history 1974: First draft of TCP/IP [“A protocol for packet network interconnection”, Vint Cerf and Robert Kahn] 1983: ARPANET switches on TCP/IP 1986: Congestion collapse 1988: Congestion control for TCP [“Congestion avoidance and control”, Van Jacobson]

DJW /24 TCP transmission control protocol Internet congestion is controlled by the end-systems The TCP algorithm, running on the server, decides how fast to send data –It sends data packets, and waits for ACKnowledgement packets –It sets a target window size w t the number of packets that have been sent but not yet acknowledged (here 5+3) –The average transmission rate is x t ≈ w t /RTT where RTT is the round trip time –It adapts w t based on the ACKs it receives User Server (TCP) data acknowledgements

DJW /24 if (seqno > _last_acked) { if (!_in_fast_recovery) { _last_acked = seqno; _dupacks = 0; inflate_window(); send_packets(now); _last_sent_time = now; return; } if (seqno < _recover) { uint32_t new_data = seqno - _last_acked; _last_acked = seqno; if (new_data < _cwnd) _cwnd -= new_data; else _cwnd=0; _cwnd += _mss; retransmit_packet(now); send_packets(now); return; } uint32_t flightsize = _highest_sent - seqno; _cwnd = min(_ssthresh, flightsize + _mss); _last_acked = seqno; _dupacks = 0; _in_fast_recovery = false; send_packets(now); return; } if (_in_fast_recovery) { _cwnd += _mss; send_packets(now); return; } _dupacks++; if (_dupacks!=3) { send_packets(now); return; } _ssthresh = max(_cwnd/2, (uint32_t)(2 * _mss)); retransmit_packet(now); _cwnd = _ssthresh + 3 * _mss; _in_fast_recovery = true; _recover = _highest_sent; } TCP transmission rate [0–100 kB/sec] time [0–8 sec]

DJW /24 How TCP shares capacity individual flow rates aggregate flow rate time available capacity

DJW /24 TCP model I: the sawtooth Consider a single link, and a single flow with round trip time RTT When the link is not congested, transmission rate x t increases by 1/RTT i 2 pkt/sec every sec When the link becomes congested, transmission rate is cut by 50% queue becomes full and packets are dropped TCP realizes there is congestion, and cuts its rate transmission rate x ( t ) queue size time * * * service capacity buffer size

DJW /24 TCP model II: billiards Consider a single link, and many flows with round trip times RTT(1), RTT(2),... When the link is not saturated, flow i increases its transmission rate x t ( i ) by 1/RTT(i) pkt/sec 2 When the link becomes saturated, some flows experience packet drops and they cut their rates Assume some probabilistic model that says which flows experience drops [Baccelli+Hong 2002] + + = * ***** *

DJW /24 TCP model III: fluid Individual TCP flows follow a sawtooth + + = + + = individual flow rates aggregate flow rate time

DJW /24 TCP model III: fluid Individual TCP flows follow a sawtooth... but many TCP flows added together are smoother –the average rate x t varies according to a time-delayed differential equation –eqn involves p t, the packet drop probability experienced by packets sent at time t [Misra+Gong+Towsley 2000, Baccelli+McDonald+Reynier 2002, after Kelly et al. 1998] + + = + + = individual flow rates aggregate flow rate time

DJW /24 Questions about queues What is the packet drop probability p? –from a critically loaded or overloaded M/M/1/B model [B+H] –from an underloaded M/M/1/B model [Kelly, Key,...] –p t =(x t -C) + /x t i.e. the loss rate caused by excess traffic [Srikant] –assume that the router sets p explicitly [M+G+T,...] How does it depend on buffer size & traffic statistics? –assorted other approximations from queueing theory [Kelly,...] How big should buffers be in Internet routers? –3 GByte? Rule of thumb says buffer = bandwidth×delay –300 MByte? buffer = bandwidth×delay/√#flows [Appenzeller+Keslassy+McKeown, 2004] –30 kByte? constant buffer size, independent of line rate [Kelly, Key,...]

DJW /24 Formulate a maths question What is the limiting queue-length process, as N , in the three regimes –large buffers B (N) =BN –intermediate buffers B (N) =B√N –small buffers B (N) =B Why are these the interesting limiting regimes? What are the alternatives? [Bain, 2003] N TCP flows Service rate NC Buffer size B (N) Round trip time RTT

DJW /24 Intermediate buffers B (N) = B√N Consider a standalone queue –fed by N Poisson flows, each of rate x pkts/sec where x varies slowly, served at rate NC, with buffer size B√N –x t =0.95 then 1.05 pkts/sec, C=1 pkt/sec, B=3 pkt Observe –queue size flips quickly from near-empty to near-full –queue size fluctuates very rapidly; busy periods have duration O(1/N) so p t is a function of instantaneous arrival rate x t –p t =(x t -C) + /x t N=50N=100N=500N=1000 queue size traffic intensity time

DJW /24 Closing the loop In the open-loop queue –we assumed Poisson inputs with slowly varying arrival rate –queue size flips quickly from near- empty to near-full –queue size fluctuates very rapidly, with busy periods of duration O(1/N), so drop probability p t is a function of instantaneous arrival rate x t In the closed-loop TCP system –the round trip time means that we can treat inputs over time [t,t+RTT] as an exogenous arrival process to the queue –the average arrival rate should vary slowly, according to a differential equation –the aggregate of many point processes converges to a Poisson process, and this carries through to queue size [Cao+Ramanan 2002] There is thus a separation of timescales –queue size fluctuates over short timescales, and we obtain p t from the open-loop M/D/1/B (N) model –TCP adapts its rate over long timescales, according to the fluid model differential equation

DJW /24 Illustration queue size [0–619pkt] drop probability [0–.3] traffic intensity [0–1] queue size [594–619pkt] time [0–5s] time [50ms] 2Gb/s link, C=50 pkt/sec/flow 5000 TCP flows RTT 150–200ms buffer 619pkt simulator htsim by Mark Handley, UCL

DJW /24 Other buffer-sizing regimes The difference in timescales between small and large buffer AQM schemes was first observed by [Deb+Srikant, 2004] queue size [0–B pkt] drop probability [0–.3] traffic intensity [0–1] queue size [(B-25)–B pkt] time [0–5s] time [50ms] small buffers B (N) =B int. buffers B (N) =B√N large buffers B (N) =BN

DJW /24 System summary x t = average traffic rate at time t p t = packet loss probability at time t C = capacity/flow B = buffer size RTT = round trip time N=# flows TCP traffic model Small buffers Intermediate buffers Large buffers

DJW /24 Stability/instability analysis For some parameter values the dynamical system is stable –we can calculate the steady-state traffic intensity, loss probability etc. For others it is unstable and there are oscillations –we can calculate the amplitude of the oscillations, either by numerical integration or by algebraic approximation [Gaurav Raina, PhD thesis, 2005] traffic intensity x t /C time

DJW /24 Instability = synchronization If the dynamical system is unstable, there will be oscillations in aggregate traffic These usually make the queue flip-flop Then there are short periods of concentrated packet loss This makes the flows become synchronized The billiards model for TCP is an extreme case of the fluid model queue size [0–619pkt] TCP window sizes [0-25pkt] time [0–5s]

DJW /24 Instability & buffer size On the basis of this analysis, we claimed –a buffer of 30–50 packets should be sufficient –intermediate buffers will make the system become synchronized, and utilization will suffer –large buffers get high utilization, but cause synchronization and delay queue size distribution [0–100%] B=10pkt B=20pkt B=30pkt B=40pkt B=50pkt B=100pkt traffic intensity distribution [85–110%] Plot by Darrell Newman, Cambridge ½=1

DJW /24 Instability & buffer size On the basis of this analysis, we claimed –a buffer of 30–50 packets should be sufficient –intermediate buffers will make the system become synchronized, and utilization will suffer –large buffers get high utilization, but cause synchronization and delay Other people ran simulations and found –small buffers lead to terribly low utilization –intermediate buffers are much better queue size distribution [0–100%] B=10pkt B=20pkt B=30pkt B=40pkt B=50pkt B=100pkt traffic intensity distribution [85–110%] Plot by Darrell Newman, Cambridge ½=1

DJW /24 Burstiness The problem is that the Poisson limit broke down –a key step in the C+R proof is showing that each flow contributes at most one packet in a busy period TCP, on a fast access link, will produce bursty traffic –sources can send an entire window-full of packets back-to-back We can estimate when the M/D/1/B model breaks down –calculate the typical duration of a busy period –count how many packets could arrive from a single source in this time –thus estimate how fast access speeds can be without the model failing For very fast access speeds, i.e. very bursty TCP traffic, a batch-M/D/1/B model is appropriate –where the batch size reflects the TCP window size

DJW /24 Burstiness & access speeds For fast access speeds, the problem of synchronization is reduced –the drop probability p(½) for a batch-M/D/1/B queue with traffic intensity ½ becomes smoother as batch size increases –a smoother p(½) function makes the dynamical system more stable Simulations of a system with a single bottleneck link with capacity NC, where each flow is throttled by a slow access link Smoothing in networks of queues is also likely to have an impact access speed = 5C 40C

DJW /24 Queueing theory at short timescales Moral: we need better measurements of Internet traffic at short timescales, and we need more tractable techniques for short-timescale queueing theory James Cruise (Cambridge) is investigating large deviations for –intermediate between the C+R Poisson limit regime and the Weiss many-flows limit regime –typical duration of busy period is O(N -(1- " ) ) –loss probability is ≈ exp(-N " I) –parsimonious traffic descriptors: it’s just like doing large deviations for batch Poisson processes –the variational problem is simple to solve buffer size N " B N flows service rate NC

DJW /24 Conclusion TCP chooses its own limit regime TCP, through its adaptive feedback mechanism, induces a fluid limit over the timescale of a round trip time The queue dynamics change fluidly over the timescale of a round trip time, and Poisson/stochastically over much shorter timescales The choice of buffer size determines which of three queueing models is relevant