Lecture 18 Congestion Control in Data Center Networks

  • Slides: 39
Download presentation
Lecture 18: Congestion Control in Data Center Networks 1

Lecture 18: Congestion Control in Data Center Networks 1

Overview • Why is the problem different from that in the Internet? • What

Overview • Why is the problem different from that in the Internet? • What are possible solutions? 2

DC Traffic Patterns • In-cast applications – Client send queries to servers – Responses

DC Traffic Patterns • In-cast applications – Client send queries to servers – Responses are synchronized • Few overlapping long flows – According to DCTCP’s measurement 3

Data Center TCP (DCTCP) Mohammad Alizadeh, Albert Greenberg, David A. Maltz, Jitendra Padhye Parveen

Data Center TCP (DCTCP) Mohammad Alizadeh, Albert Greenberg, David A. Maltz, Jitendra Padhye Parveen Patel, Balaji Prabhakar, Sudipta Sengupta, Murari Sridharan Microsoft Research Stanford University 4

Data Center Packet Transport • Large purpose-built DCs – Huge investment: R&D, business •

Data Center Packet Transport • Large purpose-built DCs – Huge investment: R&D, business • Transport inside the DC – TCP rules (99. 9% of traffic) • How’s TCP doing? 5

TCP in the Data Center • We’ll see TCP does not meet demands of

TCP in the Data Center • We’ll see TCP does not meet demands of apps. – Suffers from bursty packet drops, Incast [SIGCOMM ‘ 09], . . . – Builds up large queues: Ø Adds significant latency. Ø Wastes precious buffers, esp. bad with shallow-buffered switches. • Operators work around TCP problems. ‒ Ad-hoc, inefficient, often expensive solutions ‒ No solid understanding of consequences, tradeoffs 6

Roadmap • What’s really going on? – – Interviews with developers and operators Analysis

Roadmap • What’s really going on? – – Interviews with developers and operators Analysis of applications Switches: shallow-buffered vs deep-buffered Measurements • A systematic study of transport in Microsoft’s DCs – Identify impairments – Identify requirements • Our solution: Data Center TCP 7

Case Study: Microsoft Bing • Measurements from 6000 server production cluster • Instrumentation passively

Case Study: Microsoft Bing • Measurements from 6000 server production cluster • Instrumentation passively collects logs ‒ Application-level ‒ Socket-level ‒ Selected packet-level • More than 150 TB of compressed data over a month 8

Partition/Aggregate Application Structure TLA Picasso Art is… 1. Deadline 2. Art is=a 250 ms

Partition/Aggregate Application Structure TLA Picasso Art is… 1. Deadline 2. Art is=a 250 ms lie… …. . 3. Picasso • Time is money MLA ……… MLA 1. Ø Strict deadlines (SLAs) Deadline = 50 ms 2. The chief… 3. …. . • Missed deadline 1. Art is a lie… Ø Lower quality result “It“I'd is “Art “Computers “Inspiration your chief like “Bad isto you awork enemy lie live artists can that in as are does of imagine life acopy. makes useless. creativity poor that exist, man us is the real. ” is Deadline“Everything =“The 10 ms They but can itwith ultimate Good must realize only good lots artists find give seduction. “ of the sense. “ you money. “ you truth. steal. ” working. ” answers. ” Worker Nodes 9

Generality of Partition/Aggregate • The foundation for many large-scale web applications. – Web search,

Generality of Partition/Aggregate • The foundation for many large-scale web applications. – Web search, Social network composition, Ad selection, etc. • Example: Facebook Internet Partition/Aggregate ~ Multiget – Aggregators: Web Servers – Workers: Memcached Servers Web Servers Memcached Protocol Memcached Servers 10

Workloads • Partition/Aggregate (Query) Delay-sensitive • Short messages [50 KB-1 MB] (Coordination, Control state)

Workloads • Partition/Aggregate (Query) Delay-sensitive • Short messages [50 KB-1 MB] (Coordination, Control state) Delay-sensitive • Large flows [1 MB-50 MB] (Data update) Throughput-sensitive 11

Impairments • Incast • Queue Buildup • Buffer Pressure 12

Impairments • Incast • Queue Buildup • Buffer Pressure 12

Incast Worker 1 • Synchronized mice collide. Ø Caused by Partition/Aggregate. Aggregator Worker 2

Incast Worker 1 • Synchronized mice collide. Ø Caused by Partition/Aggregate. Aggregator Worker 2 Worker 3 RTOmin = 300 ms Worker 4 TCP timeout 13

MLA Query Completion Time (ms) Incast Really Happens • Requests are jittered over 10

MLA Query Completion Time (ms) Incast Really Happens • Requests are jittered over 10 ms window. th 99. 9 off percentile is beinghigh tracked. Jittering trades median against percentiles. • Jittering switched off around 8: 30 am. 14

In. Cast: Goodput collapses as senders increase 15

In. Cast: Goodput collapses as senders increase 15

In. Cast: Synchronized timeouts 16

In. Cast: Synchronized timeouts 16

Queue Buildup Sender 1 • Big flows buildup queues. Ø Increased latency for short

Queue Buildup Sender 1 • Big flows buildup queues. Ø Increased latency for short flows. Receiver Sender 2 • Measurements in Bing cluster Ø For 90% packets: RTT < 1 ms Ø For 10% packets: 1 ms < RTT < 15 ms 17

Data Center Transport Requirements 1. High Burst Tolerance – Incast due to Partition/Aggregate is

Data Center Transport Requirements 1. High Burst Tolerance – Incast due to Partition/Aggregate is common. 2. Low Latency – Short flows, queries 3. High Throughput – Continuous data updates, large file transfers The challenge is to achieve these three together. 18

Tension Between Requirements High Throughput High Burst Tolerance Low Latency Deep Buffers: Ø Queuing

Tension Between Requirements High Throughput High Burst Tolerance Low Latency Deep Buffers: Ø Queuing Delays Increase Latency Shallow Buffers: Ø Bad for Bursts & Throughput Reduced RTOmin (SIGCOMM ‘ 09) Ø Doesn’t Help Latency AQM – RED: Ø Avg Queue Not Fast Enough for Incast Objective: Low Queue Occupancy & High Throughput DCTCP 19

The DCTCP Algorithm 20

The DCTCP Algorithm 20

Review: The TCP/ECN Control Loop Sender 1 ECN = Explicit Congestion Notification ECN Mark

Review: The TCP/ECN Control Loop Sender 1 ECN = Explicit Congestion Notification ECN Mark (1 bit) Receiver Sender 2 21

Small Queues & TCP Throughput: The Buffer Sizing Story • Bandwidth-delay product rule of

Small Queues & TCP Throughput: The Buffer Sizing Story • Bandwidth-delay product rule of thumb: – A single flow needs buffers for 100% Throughput. Cwnd Buffer Size B Throughput 100% 17

Small Queues & TCP Throughput: The Buffer Sizing Story • Bandwidth-delay product rule of

Small Queues & TCP Throughput: The Buffer Sizing Story • Bandwidth-delay product rule of thumb: – A single flow needs buffers for 100% Throughput. • Appenzeller rule of thumb (SIGCOMM ‘ 04): – Large # of flows: is enough. Cwnd Buffer Size B Throughput 100% 17

Small Queues & TCP Throughput: The Buffer Sizing Story • Bandwidth-delay product rule of

Small Queues & TCP Throughput: The Buffer Sizing Story • Bandwidth-delay product rule of thumb: – A single flow needs buffers for 100% Throughput. • Appenzeller rule of thumb (SIGCOMM ‘ 04): – Large # of flows: is enough. • Can’t rely on stat-mux benefit in the DC. – Measurements show typically 1 -2 big flows at each server, at most 4. 17

Small Queues & TCP Throughput: The Buffer Sizing Story • Bandwidth-delay product rule of

Small Queues & TCP Throughput: The Buffer Sizing Story • Bandwidth-delay product rule of thumb: – A single flow needs buffers for 100% Throughput. • Appenzeller rule of thumb (SIGCOMM ‘ 04): – Large # of flows: is enough. • Can’t rely on stat-mux benefit in the DC. – Measurements show typically 1 -2 big flows at each server, at most 4. Real Rule of Thumb: Low Variance in Sending Rate → Small Buffers Suffice B 17

Two Key Ideas 1. React in proportion to the extent of congestion, not its

Two Key Ideas 1. React in proportion to the extent of congestion, not its presence. ü Reduces variance in sending rates, lowering queuing requirements. ECN Marks TCP DCTCP 10111 Cut window by 50% Cut window by 40% 000001 Cut window by 50% Cut window by 5% 2. Mark based on instantaneous queue length. ü Fast feedback to better deal with bursts. 18

Data Center TCP Algorithm B Switch side: – Mark packets when Queue Length >

Data Center TCP Algorithm B Switch side: – Mark packets when Queue Length > K. Mark K Don’t Mark Sender side: – Maintain running average of fraction of packets marked (α). In each RTT: Ø Adaptive window decreases: – Note: decrease factor between 1 and 2. 19

(Kbytes) DCTCP in Action Setup: Win 7, Broadcom 1 Gbps Switch Scenario: 2 long-lived

(Kbytes) DCTCP in Action Setup: Win 7, Broadcom 1 Gbps Switch Scenario: 2 long-lived flows, K = 30 KB 20

Why it Works 1. High Burst Tolerance ü Large buffer headroom → bursts fit.

Why it Works 1. High Burst Tolerance ü Large buffer headroom → bursts fit. ü Aggressive marking → sources react before packets are dropped. 2. Low Latency ü Small buffer occupancies → low queuing delay. 3. High Throughput ü ECN averaging → smooth rate adjustments, low variance. 21

Evaluation • Implemented in Windows stack. • Real hardware, 1 Gbps and 10 Gbps

Evaluation • Implemented in Windows stack. • Real hardware, 1 Gbps and 10 Gbps experiments – – 90 server testbed Broadcom Triumph Cisco Cat 4948 Broadcom Scorpion 48 1 G ports – 4 MB shared memory 48 1 G ports – 16 MB shared memory 24 10 G ports – 4 MB shared memory • Numerous micro-benchmarks – Throughput and Queue Length – Multi-hop – Queue Buildup – Buffer Pressure – Fairness and Convergence – Incast – Static vs Dynamic Buffer Mgmt • Cluster traffic benchmark 23

Cluster Traffic Benchmark • Emulate traffic within 1 Rack of Bing cluster – 45

Cluster Traffic Benchmark • Emulate traffic within 1 Rack of Bing cluster – 45 1 G servers, 10 G server for external traffic • Generate query, and background traffic – Flow sizes and arrival times follow distributions seen in Bing • Metric: – Flow completion time for queries and background flows. We use RTOmin = 10 ms for both TCP & DCTCP. 24

Baseline Background Flows Query Flows 25

Baseline Background Flows Query Flows 25

Baseline Background Flows Query Flows ü Low latency for short flows. 25

Baseline Background Flows Query Flows ü Low latency for short flows. 25

Baseline Background Flows Query Flows ü Low latency for short flows. ü High throughput

Baseline Background Flows Query Flows ü Low latency for short flows. ü High throughput for long flows. 25

Baseline Background Flows Query Flows ü Low latency for short flows. ü High throughput

Baseline Background Flows Query Flows ü Low latency for short flows. ü High throughput for long flows. ü High burst tolerance for query flows. 25

Scaled Background & Query 10 x Background, 10 x Query 26

Scaled Background & Query 10 x Background, 10 x Query 26

Scalability 37

Scalability 37

Conclusions • DCTCP satisfies all our requirements for Data Center packet transport. ü Handles

Conclusions • DCTCP satisfies all our requirements for Data Center packet transport. ü Handles bursts well ü Keeps queuing delays low ü Achieves high throughput • Features: ü Very simple change to TCP and a single switch parameter. ü Based on mechanisms already available in Silicon. 27

Discussion • What if traffic patterns change? – E. g. , many overlapping flows

Discussion • What if traffic patterns change? – E. g. , many overlapping flows • What do you like/dislike? 39