2. cnp3-ebook
3. principles/transport
4. English
5. Zen

130 ../../principles/transport.rst:770
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Three-way handshake : recovery from duplicates `CR` and `CA` 60/10000 · 60
131 ../../principles/transport.rst:774
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Data transfer 13/10000 · 13
132 ../../principles/transport.rst:776
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Now that the transport connection has been established, it can be used to transfer data. To ensure a reliable delivery of the data, the transport protocol will include sliding windows, retransmission timers and `go-back-n` or `selective repeat`. However, we cannot simply reuse the techniques from the datalink because a transport protocol needs to deal with more types of errors than a reliable protocol in datalink layer. The first difference between the two layers is the transport layer must face with more variable delays. In the datalink layer, when two hosts are connected by a link, the transmission delay or the round-trip-time over the link is almost fixed. In a network that can span the globe, the delays and the round-trip-times can vary significantly on a per packet basis. This variability can be caused by two factors. First, packets sent through a network do not necessarily follow the same path to reach their destination. Second, some packets may be queued in the buffers of routers when the load is high and these queuing delays can lead to increased end-to-end delays. A second difference between the datalink layer and the transport layer is that a network does not always deliver packets in sequence. This implies that packets may be reordered by the network. Furthermore, the network may sometimes duplicate packets. The last issue that needs to be dealt with in the transport layer is the transmission of large SDUs. In the datalink layer, reliable protocols transmit small frames. Applications could generate SDUs that are much larger than the maximum size of a packet in the network layer. The transport layer needs to include mechanisms to fragment and reassemble these large SDUs. 1709/10000 · 1709
133 ../../principles/transport.rst:778
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — To deal with all these characteristics of the network layer, we need to adapt the techniques that we have introduced in the datalink layer. 139/10000 · 139
134 ../../principles/transport.rst:780
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The first point which is common between the two layers is that both use CRCs or checksums to detect transmission errors. Each segment contains a CRC/checksum which is computed over the entire segment (header and payload) by the sender and inserted in the header. The receiver recomputes the CRC/checksum for each received segment and discards all segments with an invalid CRC. 376/10000 · 376
135 ../../principles/transport.rst:782
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Reliable transport protocols also use sequence numbers and acknowledgment numbers. While reliable protocols in the datalink layer use one sequence number per frame, reliable transport protocols consider all the data transmitted as a stream of bytes. In these protocols, the sequence number placed in the segment header corresponds to the position of the first byte of the payload in the bytestream. This sequence number allows detecting losses but also enables the receiver to reorder the out-of-sequence segments. This is illustrated in the figure below. 555/10000 · 555
136 ../../principles/transport.rst:801
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Using sequence numbers to count bytes has also one advantage when the transport layer needs to fragment SDUs in several segments. The figure below shows the fragmentation of a large SDU in two segments. Upon reception of the segments, the receiver will use the sequence numbers to correctly reorder the data. 308/10000 · 308
137 ../../principles/transport.rst:818
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Compared to reliable protocols in the datalink layer, reliable transport protocols encode their sequence numbers using more bits. 32 bits and 64 bits sequence numbers are frequent in the transport layer while some datalink layer protocols encode their sequence numbers in an 8 bits field. This large sequence number space is motivated by two reasons. First, since the sequence number is incremented for each transmitted byte, a single segment may consume one or several thousands of sequence numbers. Second, a reliable transport protocol must be able to detect delayed segments. This can only be done if the number of bytes transmitted during the MSL period is smaller than the sequence number space. Otherwise, there is a risk of accepting duplicate segments. 761/10000 · 761
138 ../../principles/transport.rst:820
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `Go-back-n` and `selective repeat` can be used in the transport layer as in the datalink layer. Since the network layer does not guarantee an in-order delivery of the packets, a transport entity should always store the segments that it receives out-of-sequence. For this reason, most transport protocols will opt for some form of selective repeat mechanism. 357/10000 · 357
139 ../../principles/transport.rst:822
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — In the datalink layer, the sliding window has usually a fixed size which depends on the amount of buffers allocated to the datalink layer entity. Such a datalink layer entity usually serves one or a few network layer entities. In the transport layer, the situation is different. A single transport layer entity serves a large and varying number of application processes. Each transport layer entity manages a pool of buffers that needs to be shared between all these processes. Transport entity are usually implemented inside the operating system kernel and shares memory with other parts of the system. Furthermore, a transport layer entity must support several (possibly hundreds or thousands) of transport connections at the same time. This implies that the memory which can be used to support the sending or the receiving buffer of a transport connection may change during the lifetime of the connection [#fautotune]_ . Thus, a transport protocol must allow the sender and the receiver to adjust their window sizes. 1019/10000 · 1019
140 ../../principles/transport.rst:824
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — To deal with this issue, transport protocols allow the receiver to advertise the current size of its receiving window in all the acknowledgments that it sends. The receiving window advertised by the receiver bounds the size of the sending buffer used by the sender. In practice, the sender maintains two state variables : `swin`, the size of its sending window (that may be adjusted by the system) and `rwin`, the size of the receiving window advertised by the receiver. At any time, the number of unacknowledged segments cannot be larger than :math:`\min(swin,rwin)` [#facklost]_ . The utilization of dynamic windows is illustrated in the figure below. 653/10000 · 653
141 ../../principles/transport.rst:830
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Dynamic receiving window 24/10000 · 24
142 ../../principles/transport.rst:832
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The receiver may adjust its advertised receive window based on its current memory consumption, but also to limit the bandwidth used by the sender. In practice, the receive buffer can also shrink as the application may not able to process the received data quickly enough. In this case, the receive buffer may be completely full and the advertised receive window may shrink to `0`. When the sender receives an acknowledgment with a receive window set to `0`, it is blocked until it receives an acknowledgment with a positive receive window. Unfortunately, as shown in the figure below, the loss of this acknowledgment could cause a deadlock as the sender waits for an acknowledgment while the receiver is waiting for a data segment. 731/10000 · 731
143 ../../principles/transport.rst:838
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Risk of deadlock with dynamic windows 37/10000 · 37
144 ../../principles/transport.rst:843
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — To solve this problem, transport protocols rely on a special timer : the `persistence timer`. This timer is started by the sender whenever it receives an acknowledgment advertising a receive window set to `0`. When the timer expires, the sender retransmits an old segment in order to force the receiver to send a new acknowledgment, and hence send the current receive window size. 380/10000 · 380
145 ../../principles/transport.rst:845
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — To conclude our description of the basic mechanisms found in transport protocols, we still need to discuss the impact of segments arriving in the wrong order. If two consecutive segments are reordered, the receiver relies on their sequence numbers to reorder them in its receive buffer. Unfortunately, as transport protocols reuse the same sequence number for different segments, if a segment is delayed for a prolonged period of time, it might still be accepted by the receiver. This is illustrated in the figure below where segment `D(1,b)` is delayed. 554/10000 · 554
146 ../../principles/transport.rst:852
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Ambiguities caused by excessive delays 38/10000 · 38
147 ../../principles/transport.rst:856
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — To deal with this problem, transport protocols combine two solutions. First, they use 32 bits or more to encode the sequence number in the segment header. This increases the overhead, but also increases the delay between the transmission of two different segments having the same sequence number. Second, transport protocols require the network layer to enforce a `Maximum Segment Lifetime (MSL)`. The network layer must ensure that no packet remains in the network for more than MSL seconds. In the Internet the MSL is assumed [#fmsl]_ to be 2 minutes :rfc:`793`. Note that this limits the maximum bandwidth of a transport protocol. If it uses `n` bits to encode its sequence numbers, then it cannot send more than :math:`2^n` segments every MSL seconds. 755/10000 · 755
148 ../../principles/transport.rst:860
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Connection release 18/10000 · 18
149 ../../principles/transport.rst:864
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — When we discussed the connection-oriented service, we mentioned that there are two types of connection releases : `abrupt release` and `graceful release`. 154/10000 · 154