Solving the TCP-Incast Problem with Application-Level Scheduling

Podlesny, Maxim; Williamson, Carey

doi:10.1109/mascots.2012.21

Cited by 22 publications

(16 citation statements)

References 22 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Within a server, interference can occur both in the incoming and outgoing direction of the network link. If a BE task causes incast interference, we can throttle its core allocation until networking flow-control mechanisms trigger [62]. In the outgoing direction, we can use traffic control mechanisms in operating systems like Linux to provide bandwidth guarantees to LC tasks and to prioritize their messages ahead of those from BE tasks [12].…”

Section: Shared Resource Interferencementioning

confidence: 99%

Heracles

Cheng

Govindaraju

et al. 2015

SIGARCH Comput. Archit. News

View full text Add to dashboard Cite

User-facing, latency-sensitive services, such as websearch, underutilize their computing resources during daily periods of low traffic. Reusing those resources for other tasks is rarely done in production services since the contention for shared resources can cause latency spikes that violate the service-level objectives of latency-sensitive tasks. The resulting under-utilization hurts both the affordability and energy-efficiency of large-scale datacenters. With technology scaling slowing down, it becomes important to address this opportunity. We present Heracles, a feedback-based controller that enables the safe colocation of best-effort tasks alongside a latencycritical service. Heracles dynamically manages multiple hardware and software isolation mechanisms, such as CPU, memory, and network isolation, to ensure that the latency-sensitive job meets latency targets while maximizing the resources given to best-effort tasks. We evaluate Heracles using production latencycritical and batch workloads from Google and demonstrate average server utilizations of 90% without latency violations across all the load and colocation scenarios that we evaluated.

show abstract

Section: Shared Resource Interferencementioning

confidence: 99%

Heracles

Cheng

Govindaraju

et al. 2015

SIGARCH Comput. Archit. News

View full text Add to dashboard Cite

show abstract

“…TCP NewReno and TCP SACK modify the congestion mechanisms to slightly increase the throughput, however do not prevent TCP Incast collapse. TCP pacing has been proposed to tackle low throughput, however it does not prevent high latencies due to queue build-up when the number of concurrent flows is high, and it is not effective in low-latency networks [20].…”

Section: Related Workmentioning

confidence: 99%

OTCP: SDN-managed congestion control for data center networks

Jouët

Perkins

Pezaros

2016

NOMS 2016 - 2016 IEEE/IFIP Network Operations and Management Symposium

View full text Add to dashboard Cite

Abstract-TCP suffers from incast collapse in data center networks when used with partition aggregate workloads due to inadequate congestion control parameters. This causes poor application performance by under-utilizing the network, and can be one of the limiting factors in low-latency, high-throughput environments. To resolve this, we present Omniscient TCP (OTCP), a Software Defined Networking (SDN) approach to compute environment-specific congestion control parameters based on centrally available network properties. Through experimental evaluation in Mininet, we show up to 12× and 31× reduction in Flow Completion Time (FCT) at the mean and 95 th percentile, an 8× FCT improvement on highly congested networks when combined with DCTCP [1], as well as improved fairness and reduced end-to-end latency.

show abstract

“…Application-Layer Approaches: The incast congestion problem can be prevented in applications, typically by restricting the number of synchronous requests [27], [33], [38], [39]. However, since a datacenter needs to support a large number of applications that cannot be easily modified, a solution at the transport layer is more preferred in many scenarios.…”

Section: A Datacenter Network Congestion Controlmentioning

confidence: 99%

Revisiting TCP Congestion Control in a Virtual Cluster Environment

Cheng

Lau

2016

IEEE/ACM Trans. Networking

View full text Add to dashboard Cite

Virtual machines (VMs) are widely adopted today to provide elastic computing services in datacenters, and they still heavily rely on TCP for congestion control. VM scheduling delays due to CPU sharing can cause frequent spurious retransmit timeouts (RTOs). Using current detection methods, we find that such spurious RTOs cannot be effectively identified because of the retransmission ambiguity caused by the delayed ACK (DelACK) mechanism. Disabling DelACK would add significant CPU overhead to the VMs and thus degrade the network's performance. In this paper, we first report our practical experience about TCP's reaction to VM scheduling delays. We then provide an analysis of the problem that has two components corresponding to VM preemption on the sender side and the receiver side, respectively. Finally, we propose PVTCP, a ParaVirtualized approach to counteract the distortion of congestion information caused by the hypervisor scheduler. PVTCP is completely embedded in the guest OS and requires no modification in the hypervisor. Taking incast congestion as an example, we evaluate our solution in a 21-node testbed. The results show that PVTCP has high adaptability in virtualized environments and deals satisfactorily with the throughput collapse problem. Index Terms-Congestion control, TCP, virtual machine.1063-6692

show abstract

Solving the TCP-Incast Problem with Application-Level Scheduling

Cited by 22 publications

References 22 publications

Heracles

Heracles

OTCP: SDN-managed congestion control for data center networks

Revisiting TCP Congestion Control in a Virtual Cluster Environment

Contact Info

Product

Resources

About