Reliable byte stream
A reliable byte stream is a common service paradigm in computer networking; it refers to a byte stream in which the bytes which emerge from the communication channel at the recipient are exactly the same, and in exactly the same order, as they were when the sender inserted them into the channel. The classic example of a reliable byte stream communication protocol is the Transmission Control Protocol, one of the major building blocks of the Internet. A reliable byte stream is not the only reliable service paradigm which computer network communication protocols provide, however; other protocols (e.g. SCTP) provide a reliable message stream, i.e. the data is divided up into distinct units, which are provided to the consumer of the data as discrete objects.
A reliable byte stream is a common service paradigm in computer networking; it refers to a byte stream in which the bytes which emerge from the communication channel at the recipient are exactly the same, and in exactly the same order, as they were when the sender inserted them into the channel.
The classic example of a reliable byte stream communication protocol is the Transmission Control Protocol, one of the major building blocks of the Internet.
A reliable byte stream is not the only reliable service paradigm which computer network communication protocols provide, however; other protocols (e.g. SCTP) provide a reliable message stream, i.e. the data is divided up into distinct units, which are provided to the consumer of the data as discrete objects.
Mechanism
[edit] |
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
[edit]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]
See also
[edit]References
[edit]- ^ a b Briscoe et al. 2016, pp. 29–30.
- ^ Langley et al. 2017, pp. 184, 186.
- ^ Marx et al. 2018, pp. 22–23.
- ^ Nowlan, Wolinsky & Ford 2013, p. 6.
- ^ Heijligers 2021, p. 65.
- Larry L. Peterson and Bruce S. Davie, Computer networks: a systems approach, 3rd edition, Morgan Kaufmann Publishers, 1996, Section 6.2.
- Steve Steinke, Network Tutorial, Elsevier, 2000, page 163.
Bibliography
[edit]- 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. Archived (PDF) from the original on 2024-04-18. Retrieved 2024-02-23.
- 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.