|
|
|
|
LEADER |
01858 am a22002053u 4500 |
001 |
137372 |
042 |
|
|
|a dc
|
100 |
1 |
0 |
|a Narayan, Akshay
|e author
|
700 |
1 |
0 |
|a Cangialosi, Frank
|e author
|
700 |
1 |
0 |
|a Goyal, Prateesh
|e author
|
700 |
1 |
0 |
|a Narayana, Srinivas
|e author
|
700 |
1 |
0 |
|a Alizadeh, Mohammad
|e author
|
700 |
1 |
0 |
|a Balakrishnan, Hari
|e author
|
245 |
0 |
0 |
|a The Case for Moving Congestion Control Out of the Datapath
|
260 |
|
|
|b ACM,
|c 2021-11-04T16:53:15Z.
|
856 |
|
|
|z Get fulltext
|u https://hdl.handle.net/1721.1/137372
|
520 |
|
|
|a © 2017 Copyright held by the owner/author(s). With Moore's law ending, the gap between general-purpose processor speeds and network link rates is widening. This trend has led to new packet-processing "datapaths" in endpoints, including kernel bypass software and emerging SmartNIC hardware. In addition, several applications are rolling out their own protocols atop UDP (e.g., QUIC,WebRTC, Mosh, etc.), forming new datapaths different from the traditional kernel TCP stack. All these datapaths require congestion control, but they must implement it separately because it is not possible to reuse the kernel's TCP implementations. This paper proposes moving congestion control from the datapath into a separate agent. This agent, which we call the congestion control plane (CCP), must provide both an expressive congestion control API as well as a specification for datapath designers to implement and deploy CCP.We propose an API for congestion control, datapath primitives, and a user-space agent design that uses a batching method to communicate with the datapath. Our approach promises to preserve the behavior and performance of indatapath implementations while making it significantly easier to implement and deploy new congestion control algorithms.
|
546 |
|
|
|a en
|
655 |
7 |
|
|a Article
|
773 |
|
|
|t 10.1145/3152434.3152438
|