# Lower-Latency Screen Updates over QUIC with Forward Error Correction
## 3 Use Case: Pixel-Based Screen Sharing Protocols  
In this paper, we discuss the benefit of applying our partial delivery mechanism combined with FEC for a specific workload called pixel-based screen sharing protocols, such as for VNC [23]. VNC is an open-source application in which a VNC server can share its screen with a VNC client/viewer by sending screen updates, while the client has control over mouse and keyboard inputs and can view some applications running on the server node. VNC mostly follows the FrameBuffer update protocol [24] for screen updates which contain the pixel data of updated parts of the screen. Each FrameBuffer update is a set of rectangles of the updated parts of the screen. VNC server sends a sequence of these updates to the client. The order of rectangles in each update is not important, but we need to keep the order of updates in the sequence in which they have been sent. That is why this kind of screen sharing protocol has partial ordering requirements, not total ordering. For example, if we have a sequence of five FrameBuffer updates (i.e, update1 to update5) and each contains 100 rectangles, we can deliver the 100 rectangles of update1 in arrival order at the client side and then start delivering the 100 rectangles of update2 in arrival order. We may receive some of the rectangles of update2 while we wait to finish delivering update1, so we need some buffer and a consistency fence between each consecutive update. VNC runs over the TCP, as it needs a reliable transport protocol to run over. The TCP enforces total ordering, while VNC needs partial ordering. That means that running VNC over the TCP does not allow us to deliver rectangles of each update in arrival order. For example, if a rectangle in the middle of an update was lost, we need to wait for its retransmission to be able to deliver the rest of rectangles of that update. This waiting time is a function of the RTT, and the user would notice it as a lag in the middle of the screen update, especially for large RTT scenarios. To improve the smoothness of delivering the screen update, we propose replacing the underlying protocol (i.e., the TCP) with a protocol which allows us to relax the order of rectangles within each update (e.g., a UDP-based protocol) while keeping the order of updates in the sequence by using the CF model. Also, adding FEC helps us to recover lost packets sooner than waiting for the retransmissions and be able to finish delivering each update to start the next update sooner. We implemented this idea over QUIC as a UDP-based protocol. The FrameBuffer update protocol is demand-driven, which means that the server sends a FrameBuffer update only after receiving an update request from the client. Although this design decision makes the protocol simple and addaptive to the client's needs and network speed, it also means that the rate of screen updates can be one update per RTT at most. Therefore, some high-performance VNC implementations, such as TigerVNC [25], add a new feature to support continuous updates, which means that the server sends as many screen updates as possible based on the network capacity to avoid congestion but with a higher rate than the original demand-driven version. This new feature is useful for workloads with high update rates such as playing videos. There is a wide range of use cases over VNC, from interactive examples such as 3D CAD, photo/video editing, and web browsing to less interactive ones such as watching a video. The performance metric of these different use cases can be different. For example, response time is an important metric for interactive use cases, while for streaming video, our goal is reducing glitches and improving smoothness. We designed two kinds of synthetic workloads to discuss the benefit of our approach over QUIC for these two ends of the spectrum:  
1. Streaming updates: The client sends one request to receive a stream of screen updates from the server (Section 6.1). 2.