# Lower-Latency Screen Updates over QUIC with Forward Error Correction
###### Abstract  
There are workloads that do not need the total data ordering enforced by the Transmission Control Protocol (TCP). For example, Virtual Network Computing (VNC) has a sequence of pixel-based updates in which the order of rectangles can be relaxed. However, VNC runs over the TCP and can have higher latency due to unnecessary blocking to ensure total ordering. By using Quick UDP Internet Connections (QUIC) as the underlying protocol, we are able to implement a partial order delivery approach, which can be combined with Forward Error Correction (FEC) to reduce data latency. Our earlier work on consistency fences provides a mechanism and semantic foundation for partial ordering. Our new evaluation on the Emulab testbed, with two different synthetic workloads for streaming and non-streaming updates, shows that our partial order and FEC strategy can reduce the blocking time and inter-delivery time of rectangles compared to total delivery. For one workload, partially ordered data with FEC can reduce the 99-percentile message-blocking time to 0.4 ms versus 230 ms with totally ordered data. That workload was with 0.5% packet loss, 100 ms Round-Trip Time (RTT), and 100 Mbps bandwidth. We study the impact of varying the packet-loss rate, RTT, bandwidth, and CCA and demonstrate that partial order and FEC latency improvements grow as we increase packet loss and RTT, especially with the emerging Bottleneck Bandwidth and Round-Trip propagation time (BBR) congestion control algorithm. l  
[table]capposition=top  
[table]capposition=top  
+++ ==WARNING: Truncated because of repetitions==
capposition=top  
++  
One general way to represent ordering constraints is as a directed acyclic graph (DAG) (Figure 1) [3]. For example, messages \(M_{1}\), \(M_{2}\), and \(M_{3}\) have no inter-message dependencies and can be delivered to the destination in any order (among those three messages), but \(M_{9}\) must be delivered before \(M_{7}\). Directed edges show the ordering constraints. Figure 2 compares total order delivery (such as with the Transmission Control Protocol (TCP)) vs. partial order delivery for Figure 1 if message \(M_{6}\) is lost. With total order delivery, we cannot deliver \(M_{7}\)-\(M_{9}\) while we are waiting for the retransmission of \(M_{6}\) (the green block). This source of latency is known as the Head-Of-Line (HOL) blocking problem. However, with partial order delivery, we can first deliver \(M_{7}\)-\(M_{9}\) after \(M_{5}\), with lower latency for those blocks, and overlap those deliveries with the retransmission of \(M_{6}\), resulting in lower total latency for delivering \(M_{1}\)-\(M_{11}\). The challenge is designing a mechanism and semantics for specifying when ordering matters and when it does not matter. We introduced the concept of a _consistency fence_ (CF) [4] as a mechanism to specify when ordering between packets and messages matter (inspired by memory fences from data consistency models [5]). In other words, CFs are a way of communicating ordering requirements between the sender and receiver. The sender inserts a CF to let the receiver know that all data before that CF need to be delivered before the data after that CF, but there is no ordering for the data between two CFs. In that work, we implemented the idea of CFs over a UDP-based Data Transfer (UDT) protocol [6] for partial order delivery and evaluated the latency improvements with and without an XOR-based Forward Error Correction (FEC) method for a synthetic workload. In our new evaluation, we use Quick UDP Internet Connections (QUIC) [7] because it supports a kind of partial ordering in which the data sent over each QUIC stream will be delivered in total order but involves no ordering among different streams. This way, QUIC can reduce the blocking time of different web resources of an HTTP/3 webpage by sending each resource over a separate stream. However, the download completion time of each resource still depends on the round-trip time (RTT) in the case of packet loss.