# Lower-Latency Screen Updates over QUIC with Forward Error Correction
## 6 Empirical Results on Emulab  
The workloads that we evaluated with the CF model have been described in the previous section. We had a sequence of \(N\) updates, i.e., update1, update2, \(\ldots\), updateN. Each update had a set of messages (i.e., rectangles for VNC). We needed to keep the order of updates so we delivered update1 completely, then started delivering update2, and so on. Therefore, we needed a CF between each two updates. Also, the delivery order of messages within each update was not considered important. We evaluated the latency of our CF implementation (i.e., partial ordering) with and without FEC over QUIC compared to the total ordering in an emulated testbed on Emulab. For the workload, we sent 300 updates, with 100 messages of size 1400 bytes per update, for a total of 140 KB per update and 42 MB for all 300 updates. We set the loss rate to \(\{0\%,0.1\%,0.5\%,1\%\}\), the RTT to \(\{50\text{ ms},100\text{ ms},200\text{ ms}\}\), the bandwidth to \(\{10\text{ Mbps},100\text{ Mbps},1\text{ Gbps}\}\), and the CCA to \(\{BBR,CUBIC\}\). We summarize these evaluation parameters in Table 1.  
As discussed earlier, our focus is not on exploring different FEC codes nor on sophisticated ways to adjust the amount of redundant data used. However, we can quantify the overheads of FEC as follows: For n/k = 1.03 (details below), each 140 KB update requires 4.2 KB (i.e., 3%) of overhead. For n/k = 1.05 and n/k = 1.1, the overheads are 5% and 10%, respectively, as expected based on the n/k ratio. Also, when the packet-loss rate is 0%, these redundant data are pure overhead, since no packets are ever lost. Figure 8: nghttp3 build configuration: use OpenFEC library [8]. Figure 6: Example configuration command line, bridge node: bandwidth, packet-loss rate, delay/latency, buffer units, buffer size. We chose a baseline setting to be able to compare and study the impact of different parameters in Table 1 separately. The baseline setting was a 0.5% packet-loss rate, 100 ms RTT, 100 Mbps bandwidth, and BBR. Therefore, to study the impact of each parameter, we kept all the other parameters the same as the baseline setting and only varied that specific one. Although the workload used is not a full-fledged application, the overall results of this evaluation show the following:  
1. **Partial+FEC reduced message-blocking and message inter-delivery time for the streaming** updates workload compared to total and partial delivery (Section 6.1). For example, the 99-percentile of message-blocking time for partial+FEC (n/k = 1.05) was 0.4 ms, while the 80-percentile of total was already 101 ms, and the 99-percentile was 230 ms (baseline setting: 0.5% loss, 100 ms RTT, 100 Mbps, BBR). See Figure 9.
2. Partial+FEC reduced the **update response time**, message inter-delivery time, and the completion time for the **non-streaming** updates workload compared to total and partial delivery (Section 6.2). For example, the 99-percentile of update response time for partial+FEC (n/k = 1.05) was 162 ms, while the 99-percentile of total was 325 ms. \begin{table}
\begin{tabular}{c c} \hline Parameter & Value \\ \hline Workload & streaming updates, non-streaming updates \\ \hline Packet loss & 0\%, 0.1\%, **0.5\%**, 1\% \\ \hline RTT & 50 ms, **100 ms**, 200 ms \\ \hline Bandwidth & 10 Mbps, **100 Mbps**, 1 Gbps \\ \hline CCA & **BBR**, CUBIC \\ \hline QUIC frame size & 1400 B \\ \hline \end{tabular}
\end{table} 
Table 1: Experimental setup on Emulab. Baseline setting in bold. Figure 9: **Partial+FEC reduced message-blocking and message inter-delivery time**. Streaming updates, **baseline** (0.5% loss, 100 ms RTT, 100 Mbps, BBR): **(a)** CDF of message-blocking time. **(b)** Message inter-delivery time in which the number of points above 100 ms is 59 for blue, 18 for gold, 1 for red, and 1 for black. Blue completed at 15.23 s, gold at 15.58 s, red at 16.09 s, and black at 16.33 s.  
Also, the completion time of partial+FEC (n/k = 1.05) was 137 v.s. 149 s for total (baseline setting: 0.5% loss, 100 ms RTT, 100 Mbps, BBR). See Figure 18.
3.