P4COM: In-Network Computation with Programmable Switches

MapReduce [4] is a programming model that is primarily designed to process large datasets on a computer cluster. The datasets are usually stored in a filesystem or in a database within the cluster. A general MapReduce workflow consists of three steps, namely a “Map” step, a “Shuffle” step and a “Reduce” step. These steps are running in sequence after the MapReduce job is launched. First in the “Map” step, each worker node or process (called “mapper”) executes a “map()” function on its local data partition and the data is stored temporarily. Second, a “Shuffle” step distributes the intermediate data generated by mappers to reducers (worker node or process that executes reduce() function). Finally, a “Reduce” step processes received data on each reducer in parallel, and the final results are returned to the user. The basic data structure of MapReduce is the pair of key-value. The “map()” function specifies how to parse data source to key-value pairs and the “reduce()” function defines the computation on values for the same key.

Several frameworks [5, 6, 7] have been proposed to do computation tasks based on the MapReduce model. In general, these frameworks assign one node as a master and the others as workers. The role of the master node is to monitor the MapReduce process, manage resources, and assign mappers and reducers to different worker nodes. A principle in task allocation is to put mappers close to data locations. Since the mappers and reducers are distributed randomly in the cluster, the “Shuffle” step will generate traffic across network devices. As shown in Figure 1, the shuffling traffic is sent from mapper to reducer over a switch fabric, forming an aggregation-style data communication pattern.

Traditional switching ASICs are designed with fixed functions. Under this property, adding a new feature requires designing and manufacturing a new ASIC, which incurs huge capital and engineering costs. However, programmable switching ASICs like Barefoot Tofino [20] and Cavium XPliant [21] make in-network computing [22] viable and deployable. They allow users to program the switch packet processing pipeline with a domain-specific language. The most well-known language to program the data plane is P4 [23] and our P4COM is based on the P4 language. In detail, network administrators are able to (i) program the switch parser to identify user-defined packet formats (e.g., containing custom fields for keys and values), (ii) program the on-chip memory to store custom state (e.g., store keys and computed values), and (iii) program the switch tables to perform custom actions (e.g., write values from stateful memory to packets).

The Barefoot Tofino switch [20] is a typical example of the new generation programmable switches. It consists of several pipelines. First, packets arriving at the front panel ports are parsed by parsers defined in data plane programs (written in P4 language). Then, the headers extracted by parsers and metadata are forwarded to an ingress pipeline. After a sequence of processing, packets go through a traffic manager and then are passed to an egress pipeline. Finally, after the egress pipeline, packets are forwarded to output ports. The processing in each pipeline is decomposed to multiple match-action tables.

Besides the stateless data (which is not preserved between packets, e.g., packet header, metadata), several stateful objects (which is preserved between packets, e.g., counters, meters, registers) are available in the Tofino switch. The most flexible stateful object is register, which is implemented using SRAM blocks and can be read/written by the data plane. Tofino switch also provides stateful arithmetic and logical units (SALUs) to perform simple computations on registers, metadata and constants. Network engineers can apply these operations to realize hash-based algorithms (e.g., bloom filters and sketches). Furthermore, the SALU modules also support additions and comparisons. This property is appealing to enable programmable switches to realize in-network computing.

We now use a typical Word Count example to illustrate the motivation behind in-network computation. In the MapReduce framework (Hadoop [5], Spark [6, 7], etc.), the Word Count benchmark runs as follows (see Figure 2):

Conventional Procedure: Source text files are located on different workers, and Map tasks are assigned to these workers. (i) Map tasks map each word (“alice”, “bob”, etc.) in the text file to tuples ($<$“alice”, 1$>$, $<$“bob”,1$>$, etc.); (ii) These tuples are sent from mappers (servers running Map task) to reducers (servers running Reduce tasks) based on their hash values; (iii) Reduce tasks accumulate the total appearance of different words ($<$“alice”, 1$>$, $<$“bob”,1$>$, etc.). Each reducer is responsible for a subset of the entire vocabulary, and the final result is the combination of the results from all reducers.

In-network Computation Procedure: Before the $<$Word, Count$>$ pairs are passed to the NIC, workers serialize their own word lists into streams of packets, and send them to the data collector. When these packets arrive at the P4COM-enabled switch, they are parsed according to the pre-defined format and complete the reducer function. Temporary $<$Word, Count$>$ pairs (e.g., $<$“alice”,2$>$ $<$“bob”,2$>$, etc.) are stored inside the switch stateful memory. Later, mappers send data collection signal packets to reducers periodically. When signal packets arrive, the switch will assemble the $<$Word, Count$>$ pairs from the memory into the signal packets, and forward them to the reducers. At last, a final reducer is executed on the reducer node, dedicated for those “unreduced” pairs.

Theoretical Analysis of In-network Computation: Offloading computation into the network can reduce the shuffling traffic volume. The shuffling traffic reduction is related to factors of key-value proportion, mapper-reducer ratio and data randomness. The key-value proportion is the packet valid payload size divided by total packet size, including header fields. In our scenario, the Tofino switch handles a packet of MTU-size at most, when transferring a certain amount of data, it may generate more packets which incurs a relatively expensive header overhead. Assume dataset of size $D$ is uniformly distributed on each mapper server, with a mapper-reducer ratio of $N:1$, the total bytes injected into the bottleneck link (last hop) in conventional manner is:

while the bottleneck data volume for in-network aggregation scenario is:

where $R$ is the key-value proportion, and $\rho$ is the randomness factor. Hence, the relative shuffling volume ratio is:

This reflects the fact that the data reduction ratio is correlated negatively to the data randomness.

Challenges of In-network Computation: However, offloading computation tasks to switches is non-trivial and has the following challenges. First, the native switch interfaces (CLI and APIs) are primarily designed for network administrators to do network configurations and monitoring, which are not friendly for application developers to program computation tasks. Second, switches have limited on-chip memory for flow tables and packet buffers, while many computation tasks require a significant amount of memory. By performing computation tasks on switches, the precious switch memory resources would soon become a bottleneck. Third, aggregation traffic may suffer from packet loss in the network. If not being correctly handled , the packet loss would cause incorrect computation results in the switches.

There are some recent work proposing similar idea of in-network computation, such as DAIET [24], iSwitch [25], SwitchML [26], and ATP [27]. DAIET [24] builds a functional prototype and is evaluated on Word Count examples. iSwitch [25] accelerates the training process of reinforcement learning applications based on NetFPGA. More recently, SwitchML [26] is proposed and considers many realistic issues, followed by ATP [27] that aims for the more generic multi-job, multi-rack scenario. However, none of these proposals simultaneously meet the requirements of user friendly, memory efficiency, and fault tolerance (see Table I). Therefore, we propose P4COM—an in-network computation framework that is user friendly, memory efficient, and fault tolerant.

P4COM targets at clusters consisting of end-hosts and programmable switch fabrics. The hosts in the cluster are labelled as master, mapper, or reducer according to their roles. The mappers and reducers are also known as worker nodes. The switch data plane is loaded with application-specific P4 program and executes in-network “reduce()” function.

Figure 3 shows the workflow of a P4COM job. The whole P4COM job life time can be partitioned into two periods. The first period includes the compilation process and configurations setup. The compiler translates application tasks into P4 programs and allocate to target switches in the network. Application-specific routing schemes are configured after the compilation and loaded through control plane channel. They are responsible for forwarding shuffling data to correct in-network switches (“reduce()” in the network). The second period is the execution of computation tasks in parallel. The mappers run local “map()” function to generate key-value pairs from data source. Intermediate data is shuffled to reducers by P4COM-specific TCP connections. During the shuffling, partial data is processed by “reduce()” on the switch data plane and temporary results are cached in the stateful memory units. Results stored in switch fabric will be forwarded to reducer periodically. Final results are collected by the reducers.

We introduce the physical components of P4COM, namely master node, worker node and switch fabric in this section.

Master. The master node is the central controller for the entire distributed application process. It is responsible for distributing mappers and reducers to worker nodes and delivering control plane messages. In our P4COM testbed, the master also runs a final reducer process, as the collection node of final key-value pairs. A shim layer is running to interpret all received packets from the P4COM switch. The master node initiates the computation workflow. Later, when intermediate data arrives, it extracts the keys and values from the packet stream. A last step reducer is executed to avoid duplicated keys in the end. When “FIN” signals are received from all reducers, the master terminates the process.

Worker (Mappers & Reducers). A distributed computation job includes multiple workers. In our prototype, each worker takes the role of a mapper or reducer. To take advantage of locality, mapper is assigned to nodes storing part of the data. Once receiving signals from the master, each mapper loads data from disk to memory and starts local “map()” processes to generate locally intermediate $<$key, value$>$ pairs. Before data is forwarded to the NIC, a shim layer is running to construct P4COM packets (see the packet header part below).

Switch. The programmable switch performs the intermediate processing for the $<$key, value$>$ pairs following Algorithm 1. The switch executes application-specific P4 programs. It detects and parses P4COM formatted packets. If new data arrives, it applies operations on the keys and values. Intermediate results are stored in the stateful memory (register arrays). When collection signal packets arrive, the switch assembles the stateful results to the payload of the signal packets and forwards to the dedicated collectors.

P4COM demands an L4 and application-layer ensembled protocol to accomplish the computation process and deal with packet losses. Similar to other MapReduce frameworks, P4COM supports commutative and associative operations. For the applications in our prototype, we utilize these basic operations that are available in the P4-supported commodity switch, namely MAX, MIN and ADDITION. In order to achieve reliability, P4COM uses a specialized TCP stack for both data streams and control message streams. The P4COM fields are appended to the P4COM-enabled TCP header. A set of TCP ports are reserved for P4COM. P4COM switches use these ports to invoke the application-specific packet processing logic for P4COM queries. Other non-P4COM switches do not have to understand the P4COM packet format. They treat P4COM related packets as normal packets.

P4COM has three types of packets, i.e., master control message, mapper data stream, and reducer data collection signal. Master control messages deliver commands and scripts to switches and servers, and these packets use the normal TCP format. Worker data streams are the packets carrying $<$key, value$>$ pairs after local computations in the mapper nodes. We show the format of data packets in Figure 4. There is no modification in L2 and L3. In L4, we apply a special cutting-payload-enabled TCP header (see the fault tolerance part below). As for the payload, we treat it as part of headers and extract them in the parser logic of P4. The first 8-bit payload is reserved for the operation (OP) field. The available OP options include MAX, MIN and ADDITION. This field informs the switch of the desired operation to execute on following key-value pairs. After the operation field, we ensemble the list of key-value pairs. For simplicity, we use 64 bytes for each key and 4 bytes for each value. The data packet can get extended to the size of MTU, which is able to carry 20 key-value pairs.

There are some technical challenges to realize P4COM with programmable switches and commodity servers.

Firstly, the domain-specific language to program the switch data plane is P4 [23]. The P4 language is primarily designed for network administrators to define parsers and match-action tables in the pipelines. The straightforward applications are network monitoring and configuration setup. However, it is not friendly to developers who express their own computation logic, especially the “reduce()” function.

Secondly, according to our protocol design, the intermediate data of $<$key, value$>$ pairs is stored inside the stateful memory. However, the memory resource (SRAM) to store stateful variables on Barefoot Tofino Switch is limited to several hundreds of Megabytes [20]. While this capacity can grow with more engineering efforts, it is still insufficient to meet the demand in distributed applications. For an application with a demand more than the limit of switch memory, we will suffer from memory overflow problem. Hence, it is impossible to store all intermediate results in the switch memory.

Thirdly, our framework has a strict requirement for packet reliability. The $<$key, value$>$ pairs inside the data packets are retrieved once arriving at the P4COM switch. To save bandwidth, a straightforward design is to drop the packet when its data is retrieved. However, it makes receivers unable to distinguish packet losses from normal retrieved packets. Furthermore, when packet drops occur, the default loss recovery mechanism in TCP may lead to incorrect result (e.g., duplicate operations for key-value pairs in the dropped packets).

To address these challenges, P4COM incorporates a micro compiler to translate application logic to P4 programs, an efficient memory management approach, and a reliability control protocol. We now describe each one of them below.

Translating application logic to P4. To facilitate the usage, we develop a programming framework for P4COM, which exposes an API for atomic operations to programmers. Programmers are assumed to be the network administrator who has complete control over all switches and servers. Programmers need to write a P4COM program consisting of the definitions of several atomic operations.

We develop a lightweight interpreter to compile the programmer-defined P4COM program. In this user-defined P4COM program, one atomic operation is dataset path setting, which assigns the IP and file path to a variable. Another operation is mapper assignment, which allocates mappers and local reducers to dedicated datasets. The last operation is reducer assignment, which allocate reducer to dedicated mappers. The compiler parses the abstract syntax tree of the program, and then uses a greedy algorithm to allocate intermediate reducers to programmable switches. The greedy objective of reducer allocation is to minimize the sum of distance between mappers and reducers. By allocating intermediate reducers to different switches, application-specific routing scheme is necessary. The compiler will also setup the routing policy for each many-to-one mapper-reducer pattern.

We provide a compile-and-run python script to launch the compilation and collect job progress information. With our P4COM micro compiler, developers can focus on their application-specific MapReduce logic without directly managing the data plane level functions.

Memory management. To address the limited memory challenge, we first leverage the fixed key space to approximate the memory occupancy on switches. We construct a heap on each mapper side, merging new keys when new packets are assembled. We set a threshold of key limit (100K in testbed) as an upper bound. This heap is used to approximate with the switch memory occupancy, with the observation that the merged key-value pairs memory is proportional to the key-only memory. Whenever the heap reaches the preset upper bound, we trigger a collection signal to the P4COM switch to push current results to the master node. At the same time, we clean the heap on the mapper and the memory on switch. This is similar to a batch algorithm in a high-level view, as we process the data one block after another.

However, as the number of mappers grows, this mechanism alone may suffer from the synchronization problem and introduce extra latency. To avoid the memory overflow problem, we propose our dynamic memory management with an extra active array inside the P4COM switch. When a new data packet arrives at the P4COM switch, the data is extracted by our parsers. For each $<$key, value$>$ from this packet, if the key hits one field in the KV arrays for intermediate results, we update its corresponding value field after the operation. In this case, no extra memory unit is consumed. Otherwise, if a key is new, we apply several hash functions to it in order to locate a new block for this $<$key, value$>$ pair storage. At the same time, we will increment a “global” memory counter, which indicates the number total distinct keys currently stored. If the counter value exceeds a certain threshold, we will modify the CP header field inside data packet, ensemble temporary KV arrays and forward to master node. When master node receives this packet, it will inform mappers to lower their sending rates. In other cases, the sending rate of the mappers follow traditional TCP congestion control algorithms, by default TCP-Cubic for Linux. With this strategy, the memory usage of programmable switch can be bounded to a reasonable limit.

Fault tolerance. Packet losses are inevitable in datacenter network due to buffer overflow, transmission error, etc. To distinguish undesired packet losses from intended P4COM packet drops, inspired by the cutting payload (CP) method [28], we develop our application-specific CP mechanism. Specifically, when data packets arrive at the switch, the parsers will extract each field including the flags in L2, L3, L4, and application-specific “payload”. After operations on the latest data and updates of switch memory, the switch will modify some flags in the CP header if state transition occurs. For example, if the memory usage is above the preset limit, the CPD flag will be set to inform the master.

We also need a mechanism to detect and react to packet losses and retransmissions. At the initialization step, our P4COM switch will allocate a register array (size equals to the number of mappers) as per-flow counters. This array is responsible for maintaining the progress states of each mapper. The values of the array are initialized to ACK sequence number of the first data packet from each mapper. When a data packet comes, the switch first compares the current ACK sequence number with the register value associated with this mapper. If the ACK is no larger than the corresponding register value, it implies that data in the packet has been processed before, and the switch will simply drop this packet. Otherwise when related operations are completed, the switch will increment the register value of the mapper by one. Hence, when duplicated packet arrives, the intermediate results will not be modified. P4 switch has an option to recirculate packet from egress to ingress. By exchanging the source and destination field of the retrieved data packet, we can generate an “ACK” packet and push back to the sender. To trace the packet sequence, it is necessary to add a monotonically increasing integer. If the sender receives a non-continuous integer, then the previous packet is supposed to be lost, and a replicated send action will be triggered on the mapper side.

The common concerns for offloading computation to the switch data plane include performance degradation and resource limitation. The Barefoot Tofino Switch provides up to 6.5 Tbps throughput, and in most cases the core network bandwidth is abundant to support distributed computation [2, 1]. In general, modern switches are equipped with tens of megabytes of on-chip memory. Since many key-value pairs are small values (e.g., $<$100-byte values for 76% read queries in the Memcached deployment at Facebook [29]), the switch on-chip memory is able to store hundreds of thousands of items for computation, leaving enough switch resources for conventional network functionalities. With our memory management scheme, the SRAM resource utilization in the switch fabric can be bounded to a constant. For large key-value pairs that do not fit in one packet, one can always divide an item into smaller chunks and retrieve them with multiple packets. Note that multiple packets would always be necessary to collect all the intermediate values stored in the switch stateful memory.

Programmers are unwilling to apply new frameworks if they have to change all programs from scratch. P4COM employs an L4 plus application layer ensembled protocol. In our prototype, we have implemented an interpreter to interact with a lightweight MapReduce framework. A shim layer parses the key-value pairs from the first stage mappers and ensemble to P4COM packets. In our prototype, users can apply our shim layer as a plugin to their programs, without modifying original versions. However, to be compatible with all existing frameworks requires more engineering efforts to parse their data structures. This extension is feasible in the technical aspect, but we leave it to future work if more users are interested to apply our P4COM framework.

P4COM is a prototype to demonstrate the feasibility of in-network computing. Due to resource limitations, all evaluations are carried out in either the Mininet simulation environment or a small testbed consisting of one Tofino switch, several commodity servers and 10Gbps links. A capacity test on a large-scale deployment is left for industry interests and future works. As for the type of MapReduce applications supported, we want to reach the limit of data plane SALU. Currently, only fixed-bit additions and comparisons are supported. Any MapReduce job that can be interpreted in this form of computation can benefit from P4COM.

Implementation. The P4COM implementation consists of controller logic, switch data plane, an interpreter on master and worker servers to interact with application data. The master distributes initial setup scripts for workers and control the computation process by constantly probing the data collection signal to the switch. Workers execute local MapReduce tasks, and construct P4COM packets with a shim layer before NIC.

In the Mininet simulations, the controller is written in Python and resides on the master node. In the testbed environment, the controller is written in specific shell scripts provided by Tofino Shell and is located in the OS of Tofino switch. Both controllers communicate with their targets through Thrift APIs at runtime. The controllers are able to update table rules, modify port configurations and monitor stateful memory.

We also implement a set of lightweight distributed MapReduce APIs in C++. It focuses on the MapReduce logic instead of the management and monitoring functions. Hence, it achieves better performance for our specific input formats compared with existing softwares (e.g., Apache Hadoop [5] and Spark [6, 7]). We apply these APIs on mapper and reducer nodes as local computation modules. Above the APIs, a Python shim layer performs translation between the local results of MapReduce program and the P4COM packets.

Dataset. For Word Count, we download several public datasets and analyze their data statistics. First, there is a Wikipedia Dumps containing 5105919 distinct keys. Second, we collect a Web Link graph data with 875713 nodes and 5105039 edges. Finally, we obtain tcpdump file from an enterprise datacenter network with 400 million packets and 20 million 5-tuple flows.

For DNN training, we refer to several recent popular models [30, 31, 32] in Image Processing domain. The statistics are shown in Table II. As for DNN training, we map the index of each model tensor to an incremental key, and then quantize the tensor cell value to match our P4COM value field. A DNN training process can be decomposed to multiple rounds of MapReduce, with the ‘reduce()’ function set to SUM.

Setup. The simulation prototype is implemented in Mininet on top of a physical server. The base operation system is Ubuntu 14.04, with a version 3.13.0 Linux kernel. The server is equipped with 24-core CPU and total 176 GB memory.

The simulation topology is shown in Figure 5 (a). We use a two-tier network topology consisting of 4 switches (2 ToRs and 2 Aggregations) and 12 hosts (6 hosts under each rack). The simulated link rates are 1Gbps between switches. We randomly split each of our datasets into partitions of equal size. Partitions of datasets are assigned to hosts logically in our tests. On mappers, there are local reducers producing first stage “reduce()” to minimize the intermediate traffic.

Schemes Compared. To show the performance gain of P4COM, we compare several scenarios of the many-to-one (number of mappers versus number of reducers) pattern. In all the tests, we implement a list of three-to-one, six-to-one and twelve-to-one mapper-reducer ratio. In each test, each mapper takes a random partition of the dataset.

• •

  Hadoop [5]. This is the baseline implemented by our lightweight distributed Hadoop framework. It aims to provide better performance compared with popular open source version.

• •

  DAIET [24]. This is the result from DAIET, which aggregates traffic in the network but without consideration of the memory efficiency and fault tolerance.

• •

  P4COM. This scheme includes all components of P4COM and implement a sorting algorithm on intermediate keys before the results are sent to the NIC. This is the general performance indicator of P4COM.

Scalability. Scalability is a key concern for any distributed computing framework. In our simulations, we provide a user-friendly interface to show how to scale P4COM to a multi-rack environment. The scripts are written in Python, interacting with the topology setting module in Mininet.

After running several jobs of multiple mappers plus multiple reducers within P4COM Mininet prototype, we find that all modules work fluently, including the core intermediate switch processing and routing. Results show that the final results of all three applications are coherent with the ones produced by conventional server-centric approaches. The routing scheme correctly distributes traffic evenly to different reducers. This proves the logical correctness of our central controller.

Incast Mitigation. One advantage of P4COM over existing server-centric frameworks is the reduction on shuffling traffic size, which often leads to the Incast problem without careful handling. We evaluate the traffic reduction ratio on different datasets in our P4COM Mininet prototype. The results are shown in Figure 6. The Y-axis implements a normalization procedure by dividing the intermediate traffic size measured in Hadoop scenario. The Ideal case is obtained based on §II-C assuming uniform data distribution and zero loss.

Our observation is that the P4COM achieves highest shuffling data reduction rate in both WikiReduce and DNN training scenarios. As the number of mappers increase, the data reduction rate becomes greater. Table II shows some sample results running DNN training jobs on P4COM. The average shuffling data reduction rate with 6 mappers work simultaneously is above 60%. Notice that the DAIET may lead to less reduction rates for the same mapper-reducer ratio compared with P4COM, due to frequent out of memory losses and trigger retransmissions frequently.

Figure 7 shows the Job Completion Time (JCT) variation according to various mapper-reducer ratio. It demonstrates that our memory management and fault tolerance mechanism can significantly reduce the shuffling process, thus leading to much smaller JCTs. We also observe a sharp increase of packet losses when increasing the mapper-reducer ratio for DAIET.

In summary, the shuffling data size reduction is related to data randomness and number of mappers. For Hadoop, the shuffling traffic grows linearly as the number of mappers increases. For DAIET, inefficient memory usage and frequent losses severely degrade its overall performance. Compared to DAIET and Hadoop, P4COM achieves much higher shuffling data reduction ratio and slower JCT increase, when increasing the mapper-reducer ratio. Based on our Mininet results, programmers can setup their own ratio of mappers and reducers according to the application requirements.

Setup. We have built a P4COM prototype on a testbed which consists of one 3.2Tbps Barefoot Tofino switch and four Huawei RH1288 V3 servers. All links between the switch and servers have the same capacity of 10Gbps. The Tofino switch has a total of 32 front panel ports. Each port is associated with a SerDes block of four lanes with a maximum throughput of 100Gbps. Each server has 24 Intel Xeon E5-2670 CPU cores and 128GB (8 x 16GB DRAM) memory. The operating system on the servers is Ubuntu 16.04.1, with the 4.10.0 Linux Kernel.

The topology of our testbed is shown in Figure 5 (b). We assign one server as master node, which distributes all computation tasks to the worker nodes. The baseline MapReduce APIs are the same as we described above. This implementation is lightweight and efficient in terms of core MapReduce logic. The shim layer is activated on each worker node. It is responsible for parsing intermediate results from local mappers and pass the data to our P4COM sockets.

Goodput Measurement. We measure the average goodput (application data transmission rate) of P4COM jobs in each mapper process. The granularity of our goodput measure is 5 seconds. We show the average goodput variation within a period of 100 seconds in Figure 8. We use $m$ to denote the number of mappers on each server. $m=1$ gives a mapper-reducer ratio of 3:1. $m=2$ means 6:1 and $m=4$ refers to 12:1. For WikiReduce benchmark, the average goodput within the whole period is 9.13 Gbps when $m=1$. Increasing $m$ to 2 and 4, we obtain 4.26 Gbps and 2.31 Gbps respectively. Similar improvements are obtained for Flows Size application and Rank Query. Our P4COM prototype implements the application-level fault-tolerance polity on top of TCP-Cubic [33]. Due to the additive-increase multiplicative-decrease (AIMD) feature of TCP-Cubic, we observe temporary goodput variance. Nevertheless, our P4COM prototype achieves near line-rate goodput throughout all test cases.