Queuing and Queue Management Reading: Sections 6.2, 6.4, 6.5 COS 461: Computer Networks Spring 2011 Mike Freedman

Slides:



Advertisements
Similar presentations
Congestion Control and Fairness Models Nick Feamster CS 4251 Computer Networking II Spring 2008.
Advertisements

Congestion Control Reading: Sections
Computer Networking Lecture 20 – Queue Management and QoS.
Congestion Control Reading: Sections
Congestion Control Reasons: - too many packets in the network and not enough buffer space S = rate at which packets are generated R = rate at which receivers.
Transport Layer – TCP (Part1) Dr. Sanjay P. Ahuja, Ph.D. Fidelity National Financial Distinguished Professor of CIS School of Computing, UNF.
ECE 4450:427/527 - Computer Networks Spring 2015
Congestion Control Created by M Bateman, A Ruddle & C Allison As part of the TCP View project.
T. S. Eugene Ngeugeneng at cs.rice.edu Rice University1 COMP/ELEC 429 Introduction to Computer Networks Lecture 16: Congestion control II Slides used with.
CS 4700 / CS 5700 Network Fundamentals Lecture 12: Router-Aided Congestion Control (Drop it like it’s hot) Revised 3/18/13.
Explicit Congestion Notification (ECN) RFC 3168 Justin Yackoski DEGAS Networking Group CISC856 – TCP/IP Thanks to Namratha Hundigopal.
Congestion Control Reading: Sections COS 461: Computer Networks Spring 2009 (MW 1:30-2:50 in CS 105) Mike Freedman Teaching Assistants: Wyatt Lloyd.
Explicit Congestion Notification ECN Tilo Hamann Technical University Hamburg-Harburg, Germany.
1 Congestion Control Outline Queuing Discipline Reacting to Congestion Avoiding Congestion.
Congestion Control Reading: Sections COS 461: Computer Networks Spring 2011 Mike Freedman
1 Internet Networking Spring 2003 Tutorial 11 Explicit Congestion Notification (RFC 3168) Limited Transmit (RFC 3042)
Analysis and Simulation of a Fair Queuing Algorithm
Transport Layer 3-1 Transport Layer r To learn about transport layer protocols in the Internet: m TCP: connection-oriented protocol m Reliability protocol.
Congestion Control and Resource Allocation
Spring 2002CS 4611 Congestion Control Outline Queuing Discipline Reacting to Congestion Avoiding Congestion.
1 Internet Networking Spring 2003 Tutorial 11 Explicit Congestion Notification (RFC 3168)
ACN: Congestion Control1 Congestion Control and Resource Allocation.
Computer Networking Lecture 17 – Queue Management As usual: Thanks to Srini Seshan and Dave Anderson.
1 Spring Semester 2007, Dept. of Computer Science, Technion Internet Networking recitation #8 Explicit Congestion Notification (RFC 3168) Limited Transmit.
Random Early Detection Gateways for Congestion Avoidance
Ns Simulation Final presentation Stella Pantofel Igor Berman Michael Halperin
Congestion Control Michael Freedman COS 461: Computer Networks
1 #6 in Mid-Term  Most answered:  many users thru the same bottleneck -> increased queueing delay -> increased e2e latency  Possible reasons behind.
CS640: Introduction to Computer Networks Aditya Akella Lecture 20 - Queuing and Basics of QoS.
CONGESTION CONTROL and RESOURCE ALLOCATION. Definition Resource Allocation : Process by which network elements try to meet the competing demands that.
Advance Computer Networking L-5 TCP & Routers Acknowledgments: Lecture slides are from the graduate level Computer Networks course thought by Srinivasan.
3: Transport Layer3b-1 TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581 r full duplex data: m bi-directional data flow in same connection m MSS: maximum.
Link Scheduling & Queuing COS 461: Computer Networks
ACN: RED paper1 Random Early Detection Gateways for Congestion Avoidance Sally Floyd and Van Jacobson, IEEE Transactions on Networking, Vol.1, No. 4, (Aug.
1 Lecture 14 High-speed TCP connections Wraparound Keeping the pipeline full Estimating RTT Fairness of TCP congestion control Internet resource allocation.
Congestion Control - Supplementary Slides are adapted on Jean Walrand’s Slides.
Queueing and Active Queue Management Aditya Akella 02/26/2007.
9.7 Other Congestion Related Issues Outline Queuing Discipline Avoiding Congestion.
CS640: Introduction to Computer Networks Aditya Akella Lecture 20 - Queuing and Basics of QoS.
AQM & TCP models Courtesy of Sally Floyd with ICIR Raj Jain with OSU.
1 CS 4396 Computer Networks Lab TCP – Part II. 2 Flow Control Congestion Control Retransmission Timeout TCP:
1 Lecture, November 27, 2002 TCP Other Internet Protocols; Internet Traffic Scalability of Virtual Circuit Networks QoS.
Handout # 14: Congestion Control
Random Early Detection (RED) Router notifies source before congestion happens - just drop the packet (TCP will timeout and adjust its window) - could make.
TCP continued. Discussion – TCP Throughput TCP will most likely generate the saw tooth type of traffic. – A rough estimate is that the congestion window.
Spring Computer Networks1 Congestion Control Sections 6.1 – 6.4 Outline Preliminaries Queuing Discipline Reacting to Congestion Avoiding Congestion.
Retransmission. Automatic Repeat reQuest (ARQ) 2 Time Packet ACK Timeout Automatic Repeat Request –Receiver sends acknowledgment (ACK) when it receives.
Queue Management Mike Freedman COS 461: Computer Networks Lectures: MW 10-10:50am in Architecture N101
Transport Layer3-1 Transport Layer If you are going through Hell Keep going.
Univ. of TehranIntroduction to Computer Network1 An Introduction Computer Networks An Introduction to Computer Networks University of Tehran Dept. of EE.
1 Lecture 15 Internet resource allocation and QoS Resource Reservation Protocol Integrated Services Differentiated Services.
11 CS716 Advanced Computer Networks By Dr. Amir Qayyum.
1 TCP ProtocolsLayer name DNSApplication TCP, UDPTransport IPInternet (Network ) WiFi, Ethernet Link (Physical)
1 Congestion and Congestion Control in Packet- Switched Networks.
Other Methods of Dealing with Congestion
Internet Networking recitation #9
Topics discussed in this section:
Chapter 3 outline 3.1 transport-layer services
Queue Management Jennifer Rexford COS 461: Computer Networks
TCP Congestion Control at the Network Edge
Queuing and Queue Management
ECE 4450:427/527 - Computer Networks Spring 2017
Other Methods of Dealing with Congestion
Other Methods of Dealing with Congestion
COS 461: Computer Networks
Internet Networking recitation #10
Congestion Control Reasons:
Transport Layer: Congestion Control
Congestion Control and Resource Allocation
Congestion Michael Freedman COS 461: Computer Networks
Presentation transcript:

Queuing and Queue Management Reading: Sections 6.2, 6.4, 6.5 COS 461: Computer Networks Spring 2011 Mike Freedman 1

Goals of Today’s Lecture Router Queuing Models – Limitations of FIFO and Drop Tail Scheduling Policies – Fair Queuing Drop policies – Random Early Detection (of congestion) – Explicit Congestion Notification (from routers) Some additional TCP mechanisms 2

Router Data and Control Planes 3 Switching Fabric Processor Line card data plane control plane

Line Cards (Interface Cards, Adaptors) Interfacing – Physical link – Switching fabric Packet handling – Packet forwarding – Decrement time-to-live – Buffer management – Link scheduling – Packet filtering – Rate limiting – Packet marking – Measurement 4 to/from link to/from switch lookup Receive Transmit

Packet Switching and Forwarding 5 R1 Link 1 Link 2 Link 3 Link 4 Link 1, ingressLink 1, egress Link 2, ingressLink 2, egress Link 3, ingressLink 3, egress Link 4, ingressLink 4, egress Choose Egress Choose Egress Choose Egress Choose Egress “4”

Router Design Issues Scheduling discipline – Which packet to send? – Some notion of fairness? Priority? Drop policy – When should you discard a packet? – Which packet to discard? Need to balance throughput and delay – Huge buffers minimize drops, but add to queuing delay (thus higher RTT, longer slow start, …) 6

FIFO Scheduling and Drop-Tail Access to the bandwidth: first-in first-out queue – Packets only differentiated when they arrive Access to the buffer space: drop-tail queuing – If the queue is full, drop the incoming packet 7 ✗

Problems with tail drop Under stable conditions, queue almost always full – Leads to high latency for all traffic Possibly unfair for flows with small windows – Larger flows may fast retransmit (detecting loss through Trip Dup ACKs), small flows may have to wait for timeout Window synchronization – More on this later… 8 ✗

Scheduling Policies (Weighted) Fair Queuing (and Class-based Quality of Service) 9

Fair Queuing (FQ) Maintains separate queue per flow Ensures no flow consumes more than its 1/n share – Variation: weighted fair queuing (WFQ) If all packets were same length, would be easy If non-work-conserving (resources can go idle), also would be easy, yet lower utilization 10 Round Robin Service Egress Link Flow 1 Flow 2 Flow 3 Flow 4

Fair Queuing Basics Track how much time each flow has used link – Compute time used if it transmits next packet Send packet from flow that will have lowest use if it transmits – Why not flow with smallest use so far? – Because next packet may be huge! 11

FQ Algorithm Imagine clock tick per bit, then tx time ~ length Finish time F i = max (F i-1, Arrive time A i ) + Length P i Calculate estimated F i for all queued packets Transmit packet with lowest F i next 12

FQ Algorithm (2) Problem: Can’t preempt current tx packet Result: Inactive flows (A i > F i-1 ) are penalized – Standard algorithm considers no history – Each flow gets fair share only when packets queued 13

FQ Algorithm (3) Approach: give more promptness to flows utilizing less bandwidth historically Bid B i = max (F i-1, A i – δ) + P i – Intuition: with larger δ, scheduling decisions calculated by last tx time F i-1 more frequently, thus preferring slower flows FQ achieves max-min fairness – First priority: maximize the minimum rate of any active flows – Second priority: maximize the second min rate, etc. 14

Uses of (W)FQ Scalability – # queues must be equal to # flows – But, can be used on edge routers, low speed links, or shared end hosts (W)FQ can be for classes of traffic, not just flows – Use IP TOS bits to mark “importance” – Part of “Differentiated Services” architecture for “Quality-of-Service” (QoS) 15

Drop Policy Drop Tail Random Early Detection (RED) Explicit Congestion Notification (ECN) 16

Bursty Loss From Drop-Tail Queuing TCP depends on packet loss – Packet loss is indication of congestion – And TCP drives network into loss by additive rate increase Drop-tail queuing leads to bursty loss – If link is congested, many packets encounter full queue – Thus, loss synchronization: Many flows lose one or more packets In response, many flows divide sending rate in half 17

Slow Feedback from Drop Tail Feedback comes when buffer is completely full – … even though the buffer has been filling for a while Plus, the filling buffer is increasing RTT – … making detection even slower Might be better to give early feedback – And get 1-2 connections to slow down before it’s too late 18

Random Early Detection (RED) Basic idea of RED – Router notices that queue is getting backlogged – … and randomly drops packets to signal congestion Packet drop probability – Drop probability increases as queue length increases – Else, set drop probability as function of avg queue length and time since last drop 19 Average Queue Length Drop Probability 0 1

Properties of RED Drops packets before queue is full – In the hope of reducing the rates of some flows Drops packet in proportion to each flow’s rate – High-rate flows have more packets – … and, hence, a higher chance of being selected Drops are spaced out in time – Which should help desynchronize the TCP senders Tolerant of burstiness in the traffic – By basing the decisions on average queue length 20

Problems With RED Hard to get tunable parameters just right – How early to start dropping packets? – What slope for increase in drop probability? – What time scale for averaging queue length? RED has mixed adoption in practice – If parameters aren’t set right, RED doesn’t help – Hard to know how to set the parameters Many other variations in research community – Names like “Blue” (self-tuning), “FRED”… 21

Feedback: From loss to notification Early dropping of packets – Good: gives early feedback – Bad: has to drop the packet to give the feedback Explicit Congestion Notification – Router marks the packet with an ECN bit – Sending host interprets as a sign of congestion 22

Explicit Congestion Notification Must be supported by router, sender, AND receiver – End-hosts determine if ECN-capable during TCP handshake ECN involves all three parties (and 4 header bits) 1.Sender marks “ECN-capable” when sending 2.If router sees “ECN-capable” and experiencing congestion, router marks packet as “ECN congestion experienced” 3.If receiver sees “congestion experienced”, marks “ECN echo” flag in responses until congestion ACK’d 4.If sender sees “ECN echo”, reduces cwnd and marks “congestion window reduced” flag in next TCP packet Why extra ECN flag? Congestion could happen in either direction, want sender to react to forward direction Why CRW ACK? ECN-echo could be lost, but we ideally only respond to congestion in forward direction 23

Other TCP Mechanisms Nagle’s Algorithm and Delayed ACK 24

Nagle’s Algorithm Wait if the amount of data is small – Smaller than Maximum Segment Size (MSS) And some other packet is already in flight – I.e., still awaiting the ACKs for previous packets That is, send at most one small packet per RTT – … by waiting until all outstanding ACKs have arrived Influence on performance – Interactive applications: enables batching of bytes – Bulk transfer: transmits in MSS-sized packets anyway 25 vs. ACK

Nagle’s Algorithm Wait if the amount of data is small – Smaller than Maximum Segment Size (MSS) And some other packet is already in flight – I.e., still awaiting the ACKs for previous packets That is, send at most one small packet per RTT – … by waiting until all outstanding ACKs have arrived Influence on performance – Interactive applications: enables batching of bytes – Bulk transfer: transmits in MSS-sized packets anyway 26 vs. ACK Turning Nagle Off void tcp_nodelay (int s) { int n = 1; if (setsockopt (s, IPPROTO_TCP, TCP_NODELAY, (char *) &n, sizeof (n)) < 0) warn ("TCP_NODELAY: %m\n"); } Turning Nagle Off void tcp_nodelay (int s) { int n = 1; if (setsockopt (s, IPPROTO_TCP, TCP_NODELAY, (char *) &n, sizeof (n)) < 0) warn ("TCP_NODELAY: %m\n"); }

Motivation for Delayed ACK TCP traffic is often bidirectional – Data traveling in both directions – ACKs traveling in both directions ACK packets have high overhead – 40 bytes for the IP header and TCP header – … and zero data traffic Piggybacking is appealing – Host B can send an ACK to host A – … as part of a data packet from B to A 27

TCP Header Allows Piggybacking 28 Source portDestination port Sequence number Acknowledgment Advertised window HdrLen Flags 0 ChecksumUrgent pointer Options (variable) Data Flags: SYN FIN RST PSH URG ACK

Example of Piggybacking 29 Data Data+ACK Data A B ACK Data Data + ACK B has data to send A has data to send B doesn’t have data to send

Increasing Likelihood of Piggybacking Example: ssh or even HTTP – Host A types command – Host B receives and executes the command – … and then data are generated – Would be nice if B could send the ACK with the new data Increase piggybacking – TCP allows the receiver to wait to send the ACK – … in the hope that the host will have data to send 30 Data Data+ACK Data A B ACK Data Data + ACK

Delayed ACK Delay sending an ACK – Upon receiving a packet, the host B sets a timer Typically, 200 msec or 500 msec – If B’s application generates data, go ahead and send And piggyback the ACK bit – If the timer expires, send a (non-piggybacked) ACK Limiting the wait – Timer of 200 msec or 500 msec – ACK every other full-sized packet 31

Conclusions Congestion is inevitable – Internet does not reserve resources in advance – TCP actively tries to push the envelope – TCP can react to congestion (multiplicative decrease) Active Queue Management can further help – Random Early Detection (RED) – Explicit Congestion Notification (ECN) Fundamental tensions – Feedback from the network? – Enforcement of “TCP friendly” behavior? Other scheduling policies (FQ) can given stronger guarantees 32