Reliable byte stream

Communication protocols that implement reliable byte streams, generally over some unreliable lower level, use a number of mechanisms to provide that reliability. Automatic repeat request (ARQ) protocols have an important role for achieving reliability.

All data items are identified with a sequence number, which is used both to make sure that the data are delivered to the entity at the other end in the correct order, and to check for lost data items. The receiver sends back acknowledgements for data items that have been successfully received; a timer at the sender will cause a timeout if an acknowledgement is not received within a reasonable round trip time, and the (presumably lost) data will then be re-transmitted. To check that no data items are damaged, a checksum is used; one is computed at the sender for each block of data before it is sent and checked at the receiver. Erroneous or missing data are reported to the sender, in order that it may retransmit the same. Any duplicated data items are discarded.

Head-of-line blocking can occur in reliable byte streams: if packets are reordered or lost and need to be retransmitted (and thus arrive out-of-order), data from sequentially later parts of the stream may be received before sequentially earlier parts of the stream; however, the later data cannot typically be used until the earlier data has been received, incurring network latency. If multiple independent higher-level messages are encapsulated and multiplexed onto a single reliable byte stream, then head-of-line blocking can cause processing of a fully-received message that was sent later to wait for delivery of a message that was sent earlier.^[1] This affects, for example, HTTP/2, which frames multiple request–response pairs onto a single stream; HTTP/3, which has an application-layer framing design and uses datagram rather than stream transport, avoids this problem.^[2][3] The latency degradation from head-of-line blocking depends on the underlying packet loss rate and round-trip time, with higher losses producing worse latency.^[4][5] Without changing the stream abstraction, reducing packet loss can reduce the harm from head-of-line blocking; an alternative is to implement the reliable byte stream using forward error correction to send redundant data so that a certain amount of loss can be tolerated without incurring retransmissions.^[1]

• Automatic repeat request

• Briscoe, Bob; Brunstrom, Anna; Petlund, Andreas; Hayes, David; Ros, David; Tsang, Ing-Jyh; Gjessing, Stein; Fairhurst, Gorry; Griwodz, Carsten; Welzl, Michael (2016). "Reducing Internet Latency: A Survey of Techniques and Their Merits". IEEE Communications Surveys & Tutorials. 18 (3): 2149–2196. doi:10.1109/COMST.2014.2375213. hdl:2164/8018. S2CID 206576469.
• Heijligers, Jaap (2021). Tor over QUIC (Thesis).
• Langley, Adam; Riddoch, Alistair; Wilk, Alyssa; Vicente, Antonio; Krasic, Charles; Zhang, Dan; Yang, Fan; Kouranov, Fedor; Swett, Ian; Iyengar, Janardhan; Bailey, Jeff; Dorfman, Jeremy; Roskind, Jim; Kulik, Joanna; Westin, Patrik; Tenneti, Raman; Shade, Robbie; Hamilton, Ryan; Vasiliev, Victor; Chang, Wan-Teh; Shi, Zhongyi (2017). "The QUIC Transport Protocol". Proceedings of the Conference of the ACM Special Interest Group on Data Communication. pp. 183–196. doi:10.1145/3098822.3098842. ISBN 9781450346535. S2CID 2768765.
• Marx, Robin; Wijnants, Maarten; Quax, Peter; Faes, Axel; Lamotte, Wim (2018). "Web Performance Characteristics of HTTP/2 and Comparison to HTTP/1.1" (PDF). Web Information Systems and Technologies. Lecture Notes in Business Information Processing. Vol. 322. pp. 87–114. doi:10.1007/978-3-319-93527-0_5. hdl:1942/26146. ISBN 978-3-319-93526-3. S2CID 52009597.
• Nowlan, Michael F.; Wolinsky, David; Ford, Bryan (2013). Reducing Latency in Tor Circuits with Unordered Delivery. 3rd USENIX Workshop on Free and Open Communications on the Internet.