Session

Can Homa and TCP Get Along?

Speakers

John Ousterhout

Label

Nuts and Bolts

Session Type

Talk

Description

The Homa transport protocol differs significantly from TCP: for example, it uses receiver-driven congestion control instead of sender-driven, it is message-based rather than stream-oriented, and it takes advantage of priority queues in network switches. This raises concerns about what happens when both protocols are used simultaneously: do the protocols interfere with each other?

This talk will consist of three parts. In the first part I will discuss initial performance measurements of TCP and Homa running concurrently, which show that TCP performance actually improves slightly when running with Homa (because Homa reduces buffer utilization) but Homa’s performance degrades drastically (because TCP still overloads buffers). In the second part of the talk I will describe homa_qdisc, a new queuing discipline that paces output traffic for both Homa and TCP to prevent queue buildup in the NIC; homa_qdisc also implements Homa’s SRPT policy and implements a limited form of SRPT for TCP as well. When output congestion occurs, homa_qdisc balances output traffic between Homa and TCP. In the third part of the talk I will present performance measurements of TCP and Homa running with homa_disc. When TCP and Homa run concurrently, homa_qdisc improves performance for both protocols: Homa now suffers only slight degradation in the face of competing TCP traffic, and TCP latency is even better with homa_qdisc than without. In addition, when TCP runs without Homa, homa_qdisc improves tail latency for short messages by almost a factor of 2 relative to fq_codel.