Shuihai Hu, Wei Bai, Kai Chen, Chen Tian (NJU), Ying Zhang (HP Labs), Haitao Wu (Microsoft) Sing Hong Kong University of Science and Technology.

Slides:



Advertisements
Similar presentations
Martin Suchara, Ryan Witt, Bartek Wydrowski California Institute of Technology Pasadena, U.S.A. TCP MaxNet Implementation and Experiments on the WAN in.
Advertisements

Congestion Control and Fairness Models Nick Feamster CS 4251 Computer Networking II Spring 2008.
Computer Networking Lecture 20 – Queue Management and QoS.
CSIT560 Internet Infrastructure: Switches and Routers Active Queue Management Presented By: Gary Po, Henry Hui and Kenny Chong.
Playback-buffer Equalization for Streaming Media using Stateless Transport Prioritization Dan Tan, HPL, Palo Alto Weidong Cui, UC Berkeley John Apostolopoulos,
Congestion Control Created by M Bateman, A Ruddle & C Allison As part of the TCP View project.
CS 268: Lecture 7 (Beyond TCP Congestion Control) Ion Stoica Computer Science Division Department of Electrical Engineering and Computer Sciences University.
1 Updates on Backward Congestion Notification Davide Bergamasco Cisco Systems, Inc. IEEE 802 Plenary Meeting San Francisco, USA July.
Advanced Computer Networking Congestion Control for High Bandwidth-Delay Product Environments (XCP Algorithm) 1.
Congestion Control An Overview -Jyothi Guntaka. Congestion  What is congestion ?  The aggregate demand for network resources exceeds the available capacity.
Ion Stoica, Scott Shenker, and Hui Zhang SIGCOMM’98, Vancouver, August 1998 subsequently IEEE/ACM Transactions on Networking 11(1), 2003, pp Presented.
XCP: Congestion Control for High Bandwidth-Delay Product Network Dina Katabi, Mark Handley and Charlie Rohrs Presented by Ao-Jan Su.
The War Between Mice and Elephants Presented By Eric Wang Liang Guo and Ibrahim Matta Boston University ICNP
Congestion control in data centers
Congestion Control Tanenbaum 5.3, /12/2015Congestion Control (A Loss Based Technique: TCP)2 What? Why? Congestion occurs when –there is no reservation.
CAC and Scheduling Schemes for Real-time Video Applications in IEEE Networks Ou Yang UR 10/11/2006.
Defense: Christopher Francis, Rumou duan Data Center TCP (DCTCP) 1.
EE689 Lecture 5 Review of last lecture More on HPF RED.
Congestion Control and Resource Allocation
1 Minseok Kwon and Sonia Fahmy Department of Computer Sciences Purdue University {kwonm, TCP Increase/Decrease.
1 Emulating AQM from End Hosts Presenters: Syed Zaidi Ivor Rodrigues.
Efficient Internet Traffic Delivery over Wireless Networks Sandhya Sumathy.
ACN: Congestion Control1 Congestion Control and Resource Allocation.
Information-Agnostic Flow Scheduling for Commodity Data Centers
Congestion Control for High Bandwidth-delay Product Networks 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,
Mohammad Alizadeh, Abdul Kabbani, Tom Edsall,
ICTCP: Incast Congestion Control for TCP in Data Center Networks∗
Practical TDMA for Datacenter Ethernet
Mohammad Alizadeh Stanford University Joint with: Abdul Kabbani, Tom Edsall, Balaji Prabhakar, Amin Vahdat, Masato Yasuda HULL: High bandwidth, Ultra Low-Latency.
Bell Labs Advanced Technologies EMEAAT Proprietary Information © 2004 Lucent Technologies1 Overview contributions for D27 Lucent Netherlands Richa Malhotra.
Network Sharing Issues Lecture 15 Aditya Akella. Is this the biggest problem in cloud resource allocation? Why? Why not? How does the problem differ wrt.
Curbing Delays in Datacenters: Need Time to Save Time? Mohammad Alizadeh Sachin Katti, Balaji Prabhakar Insieme Networks Stanford University 1.
3: Transport Layer3b-1 Principles of Congestion Control Congestion: r informally: “too many sources sending too much data too fast for network to handle”
Transport Layer3-1 Chapter 3 outline r 3.1 Transport-layer services r 3.2 Multiplexing and demultiplexing r 3.3 Connectionless transport: UDP r 3.4 Principles.
Enhancing TCP Fairness in Ad Hoc Wireless Networks Using Neighborhood RED Kaixin Xu, Mario Gerla University of California, Los Angeles {xkx,
Principles of Congestion Control Congestion: informally: “too many sources sending too much data too fast for network to handle” different from flow control!
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.
Congestion Control - Supplementary Slides are adapted on Jean Walrand’s Slides.
TTM1: ”Burst, packet and hybrid switching in the optical core network” Steinar Bjørnstad et al.
1 IEEE Meeting July 19, 2006 Raj Jain Modeling of BCN V2.0 Jinjing Jiang and Raj Jain Washington University in Saint Louis Saint Louis, MO
TCP Trunking: Design, Implementation and Performance H.T. Kung and S. Y. Wang.
Queueing and Active Queue Management Aditya Akella 02/26/2007.
Wei Bai with Li Chen, Kai Chen, Dongsu Han, Chen Tian, Hao Wang SING HKUST Information-Agnostic Flow Scheduling for Commodity Data Centers 1 SJTU,
T. S. Eugene Ngeugeneng at cs.rice.edu Rice University1 COMP/ELEC 429/556 Introduction to Computer Networks Principles of Congestion Control Some slides.
Thoughts on the Evolution of TCP in the Internet (version 2) Sally Floyd ICIR Wednesday Lunch March 17,
We used ns-2 network simulator [5] to evaluate RED-DT and compare its performance to RED [1], FRED [2], LQD [3], and CHOKe [4]. All simulation scenarios.
Explicit Allocation of Best-Effort Service Goal: Allocate different rates to different users during congestion Can charge different prices to different.
Mitigating starvation in Wireless Ad hoc Networks: Multi-channel MAC and Power Control Adviser : Frank, Yeong-Sung Lin Presented by Shin-Yao Chen.
XCP: eXplicit Control Protocol Dina Katabi MIT Lab for Computer Science
Jiaxin Cao, Rui Xia, Pengkun Yang, Chuanxiong Guo,
HP Labs 1 IEEE Infocom 2003 End-to-End Congestion Control for InfiniBand Jose Renato Santos, Yoshio Turner, John Janakiraman HP Labs.
Queue Management Mike Freedman COS 461: Computer Networks Lectures: MW 10-10:50am in Architecture N101
1 Sheer volume and dynamic nature of video stresses network resources PIE: A lightweight latency control to address the buffer problem issue Rong Pan,
1 Three ways to (ab)use Multipath Congestion Control Costin Raiciu University Politehnica of Bucharest.
MMPTCP: A Multipath Transport Protocol for Data Centres 1 Morteza Kheirkhah University of Edinburgh, UK Ian Wakeman and George Parisis University of Sussex,
6.888 Lecture 6: Network Performance Isolation Mohammad Alizadeh Spring
Low-Latency Software Rate Limiters for Cloud Networks
Resilient Datacenter Load Balancing in the Wild
HyGenICC: Hypervisor-based Generic IP Congestion Control for Virtualized Data Centers Conference Paper in Proceedings of ICC16 By Ahmed M. Abdelmoniem,
Queue Management Jennifer Rexford COS 461: Computer Networks
Generalizing The Network Performance Interference Problem
Congestion Control and Resource Allocation
Hamed Rezaei, Mojtaba Malekpourshahraki, Balajee Vamanan
Augmenting Proactive Congestion Control with Aeolus
AMP: A Better Multipath TCP for Data Center Networks
Lecture 17, Computer Networks (198:552)
Transport Layer: Congestion Control
Congestion Control and Resource Allocation
Presentation transcript:

Shuihai Hu, Wei Bai, Kai Chen, Chen Tian (NJU), Ying Zhang (HP Labs), Haitao Wu (Microsoft) Sing Hong Kong University of Science and Technology Providing Bandwidth Guarantees, Work Conservation and Low Latency Simultaneously in the Cloud 1 IEEE INFOCOM 2016, San Francisco, USA

Today’s public cloud is shared by multiple tenants running various applications. Multi-tenant Public Cloud 2

Bandwidth guarantees for throughput- intensive applications – In public cloud, network is shared by all tenants. – Bandwidth guarantee can offer predictable performance for tenants’ applications. Three Goals 3

Bandwidth guarantees for throughput- intensive applications Work conservation to fully utilize network bandwidth – Tenants can make use of spare bandwidth from unallocated or underutilized bandwidth guarantee – Significantly improve performance. 4 Three Goals

Bandwidth guarantees for throughput- intensive applications Work conservation to fully utilize the network bandwidth Low latency for latency-sensitive short messages – Improve the performance of user-facing applications. 5 Three Goals

Related Works 6 Oktopus [SIGCOMM’11] – Provides bandwidth guarantees but not work conserving. EyeQ [NSDI’13] – Requires the network core to be congestion-free. ElasticSwitch [SIGCOMM’13] – A fundamental tradeoff between bandwidth guarantees and work conservation. Silo [SIGCOMM’15] – Cannot achieve work conservation due to the tradeoff between work conservation and low latency

Related Works 7 Oktopus [SIGCOMM’11] – Provides bandwidth guarantees but not work conserving. EyeQ [NSDI’13] – Requires the network core to be congestion-free. ElasticSwitch [SIGCOMM’13] – A fundamental tradeoff between bandwidth guarantees and work conservation. Silo [SIGCOMM’15] – Cannot achieve work conservation due to the tradeoff between work conservation and low latency

Related Works Oktopus [SIGCOMM’11] – Provides bandwidth guarantees but not work conserving. EyeQ [NSDI’13] – Requires the network core to be congestion-free. ElasticSwitch [SIGCOMM’13] – A fundamental tradeoff between bandwidth guarantees and work conservation. Silo [SIGCOMM’15] – Cannot achieve work conservation due to the tradeoff between work conservation and low latency. 8

Question How to provide bandwidth guarantees, work conservation and low latency simultaneously in commodity data centers? 9

Design Goal 1 10 Eliminate the tradeoff between bandwidth guarantee and work conservation

How to provide bandwidth guarantees, work conservation and low latency simultaneously in commodity data centers? Design Goal 2 11 Eliminate the tradeoff between work conservation and low latency

How to provide bandwidth guarantees, work conservation and low latency simultaneously in commodity data centers? Design Goal 3 12 Readily-deployable: Work with existing commodity switches & be compatible with legacy network stacks

Question How to provide bandwidth guarantees, work conservation and low latency simultaneously without any tradeoff in commodity data centers? Our answer: Trinity 13

Trinity’S DESIGN 14

At the core, Trinity is an in-network isolation solution. Design Overview 15 low priority high priority VM1 Sender Module VM3 Sender Module Receiver Module VM2 VM4 end-hostsnetworkend-hosts

Differentiate traffic of bandwidth guarantees from that of work conservation with two colors at the sender. Design Overview 16 low priority high priority VM1 Sender Module VM3 Sender Module Receiver Module VM2 VM4 end-hostsnetworkend-hosts

Enforce strict priority queueing with two priority queues to decouple bandwidth guarantee traffic from work-conserving traffic. Design Overview 17 low priority high priority VM1 Sender Module VM3 Sender Module Receiver Module VM2 VM4 end-hostsnetworkend-hosts

Send congestion feedback to senders and handle possible packet-reordering problem. Design Overview 18 low priority high priority VM1 Sender Module VM3 Sender Module Receiver Module VM2 VM4 end-hostsnetworkend-hosts

With in-network isolation, low latency for short flows can be easily achieved. – Set a threshold to identify short flows at the sender module. – According to this threshold, Sender module colors the first few packets of every new flow as green to assign high priority to packets of short flows. – Threshold can be statically set as a few or tens of KBs, or also leverage some advanced thresholding schemes (e.g., PIAS) to dynamically adjust this threshold. Design Overview 19

Sender module will color part of the packets as red when application demand is larger than bandwidth guarantee. 20 low priority high priority VM1 Sender Module VM3 Sender Module VM2 VM4 networkend-hosts Simple Example Illustrating Trinity end-hosts Receiver Module

Red packets will enter the low priority queue and can utilize spare bandwidth when the high priority is empty. 21 low priority high priority VM1 Sender Module VM3 Sender Module VM2 VM4 networkend-hosts Simple Example Illustrating Trinity end-hosts

Sender module tracks per-flow information and ensure packets of short flows are colored as green. 22 low priority high priority VM1 Sender Module VM3 Sender Module VM2 VM4 networkend-hosts Simple Example Illustrating Trinity end-hosts Receiver Module Threshold to identify short flows

In the network, packets of short flows will enter high priority queue and experience little queueing delay (thus achieve low latency). 23 low priority high priority VM1 Sender Module VM3 Sender Module VM2 VM4 networkend-hosts 2 2 Simple Example Illustrating Trinity end-hosts Receiver Module

24 Issue #1: How to do efficient rate control for good work-conservation? Solution: Adopt ECN marking in network to assist rate control. Issue #2: how to handle packet trapping problem? Solution: The receivers detect the possible packet trapping problems and notify the senders. Issue #3: how to handle packet re-ordering problem? Solution: introduce a color transition delay at the sender and adopt a re-sequencing buffer at the receiver. Handle Design Issues Refer to our paper for more details.

Testbed Experiments Trinity prototype – Testbed Setup – Two Gigabit Pronto-3295 switches – 16 Dell servers Compared schemes – No Protection – Static Reservation – ElasticSwitch 25

Experiment-1: Bandwidth Guarantees and Work Conservation 26 L = 1Gbps Bottleneck link A2A1 B2B1 … Both tenants are provisioned with 300Mbps guarantees. A1 sends traffic to A2 using one TCP connection. B1 sends traffic to B2 using different numbers of TCP connections.

Experiment-1: Bandwidth Guarantees and Work Conservation 27 No protection scheme cannot provide any bandwidth guarantee. Average throughput of VM A2 under four schemes

Experiment-1: Bandwidth Guarantees and Work Conservation 28 Static reservation cannot utilize any spare bandwidth. Average throughput of VM A2 under four schemes

Experiment-1: Bandwidth Guarantees and Work Conservation 29 Average throughput of VM A2 under four schemes ElasticSwitch provides bandwidth guarantees and utilizes part of the spare bandwidth.

30 Trinity provides bandwidth guarantees and fully utilizes all the spare bandwidth. Experiment-1: Bandwidth Guarantees and Work Conservation Average throughput of VM A2 under four schemes

31 L = 1Gbps Bottleneck link A2A1 B2B1 … Three tenants A, B and C are provisioned with 200Mbps, 400Mbps and 400Mbps guarantee, respectively. A1 sends 1KB or 20KB short flows to A2 periodically. B1 and C1 send long flows to B2 and C2, respectively. C2C1 … Experiment-2: Low Latency for Short Flows

Compared to ElasticSwitch, Trinity reduces the FCT by 33% on average and by 71% at the 99 th percentile for 1KB short flows 32 Flow completion time (FCT) of short flows Experiment-2: Low Latency for Short Flows

Compared to ElasticSwitch, Trinity reduces the FCT by 38% on average and by 70% at the 99 th percentile for 20KB short flows 33 Flow completion time (FCT) of short flows Experiment-2: Low Latency for Short Flows

By letting packets of short flows receive high priority in the network, Trinity can improve the FCT of short flows significantly. 34 Flow completion time (FCT) of short flows Experiment-2: Low Latency for Short Flows

Conclusion Three goals – Bandwidth Guarantee – Work Conservation – Low Latency Core of Trinity design: in-network isolation. – End-host coloring. – In-network prioritizing. 35

Thanks! 36

Backup slides 37

Persistent Connections Solution: periodically reset flow states based on more behaviors of traffic – When a flow idles for some time, we reset the bytes sent of this flow to 0. – Define a flow as packets demarcated by incoming packets with payload within a single connection 38

Sender module will color all the packets as green when application demand is no larger than bandwidth guarantee. 39 low priority high priority VM1 Sender Module VM3 Sender Module VM2 VM4 networkend-hosts Simple Example Illustrating Trinity end-hosts Receiver Module

Green packets will enter high priority queue and enjoy guaranteed throughput in the network. 40 low priority high priority VM1 Sender Module VM3 Sender Module VM2 VM4 networkend-hosts Simple Example Illustrating Trinity end-hosts

41 Packet Re-ordering Problem Long flows may suffer from packet re-ordering problem when the color of its packets alternates from red to green

42 Rate Control Algorithm Too aggressive rate control will lead to a lot of packet drops and hence hurt the performance of TCP flows.

43 Rate Control Algorithm Too conservative rate control will lead to poor work-conservation and wastes a lot of spare bandwidth in the network. Spare bandwidth Time Rate guaranteed bandwidth

44 Rate Control Algorithm Ideal rate control should keep the occupancy of low priority queue at a moderate range to fully utilize spare bandwidth and avoid packet drops. Spare bandwidth Time Rate guaranteed bandwidth

45 Rate Control Algorithm Receiver Module Sender Module Adopt ECN marking in network to assist rate control. – Receiver module sends ECN-based congestion information to sender module periodically. – Sender module update the current sending rate according to the congestion feedback. low priority high priority Congestion feedback ECN marking threshold

46 Problem #2: how to handle packet trapping problem?

47 Packet Trapping Problem Red packets will get trapped in the network when there is no spare bandwidth (green packets already fully utilize the link capacity). get trapped in the low priority queue

48 Packet Trapping Problem Receiver Module Sender Module Receiver module sends packet trapping notification to sender module when no red packets is received in the last time period. Sender module reduces the sending rate of red packets to a small value after the packet trapping problem is confirmed. low priority high priority Packet trapping notification

49 Problem #3: how to handle packet re- ordering problem?

50 Packet Re-ordering Problem Long flows may suffer from packet re-ordering problem when the color of its packets alternates from red to green

51 Packet Re-ordering Problem At the sender, we introduce a color transition delay (denoted as τ) to mitigate packet re- ordering problem. – When there is a need to change the colors of packets from red to green, we defer the change by τ seconds.  Reserve some additional time for the red packets to transmit.  Seek the opportunity for some other flows without re- ordering issue to consume guarantee quotas instead.

52 Packet Re-ordering Problem At the sender, we introduce a color transition delay (denoted as τ) to minimize the case that packets of a flow alternate from red back to green. At the receiver, we adopt a re-sequencing buffer to absorb possible out-of-order packets.