2. cnp3-ebook
3. protocols/tcp
4. English
5. Zen

152 ../../protocols/tcp.rst:486
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The first extension that was proposed is the fast retransmit heuristic. This extension can be implemented on TCP senders and thus does not require any change to the protocol. It only assumes that the TCP receiver is able to buffer out-of-sequence segments. 256/10000 · 256
153 ../../protocols/tcp.rst:488
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — From a performance point of view, one issue with TCP's `retransmission timeout` is that when there are isolated segment losses, the TCP sender often remains idle waiting for the expiration of its retransmission timeouts. Such isolated losses are frequent in the global Internet [Paxson99]_. A heuristic to deal with isolated losses without waiting for the expiration of the retransmission timeout has been included in many TCP implementations since the early 1990s. To understand this heuristic, let us consider the figure below that shows the segments exchanged over a TCP connection when an isolated segment is lost. 619/10000 · 619
154 ../../protocols/tcp.rst:494
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Detecting isolated segment losses 33/10000 · 33
155 ../../protocols/tcp.rst:496
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — As shown above, when an isolated segment is lost the sender receives several `duplicate acknowledgments` since the TCP receiver immediately sends a pure acknowledgment when it receives an out-of-sequence segment. A duplicate acknowledgment is an acknowledgment that contains the same `acknowledgment number` as a previous segment. A single duplicate acknowledgment does not necessarily imply that a segment was lost, as a simple reordering of the segments may cause duplicate acknowledgments as well. Measurements [Paxson99]_ have shown that segment reordering is frequent in the Internet. Based on these observations, the `fast retransmit` heuristic has been included in most TCP implementations. It can be implemented as follows. 732/10000 · 732
156 ../../protocols/tcp.rst:510
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — This heuristic requires an additional variable in the TCB (`dupacks`). Most implementations set the default number of duplicate acknowledgments that trigger a retransmission to 3. It is now part of the standard TCP specification :rfc:`2581`. The `fast retransmit` heuristic improves the TCP performance provided that isolated segments are lost and the current window is large enough to allow the sender to send three duplicate acknowledgments. 443/10000 · 443
157 ../../protocols/tcp.rst:512
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The figure below illustrates the operation of the `fast retransmit` heuristic. 78/10000 · 78
158 ../../protocols/tcp.rst:518
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — TCP fast retransmit heuristics 30/10000 · 30
159 ../../protocols/tcp.rst:523
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — When losses are not isolated or when the windows are small, the performance of the `fast retransmit` heuristic decreases. In such environments, it is necessary to allow a TCP sender to use a selective repeat strategy instead of the default go-back-n strategy. Implementing selective-repeat requires a change to the TCP protocol as the receiver needs to be able to inform the sender of the out-of-order segments that it has already received. This can be done by using the Selective Acknowledgments (SACK) option defined in :rfc:`2018`. This TCP option is negotiated during the establishment of a TCP connection. If both TCP hosts support the option, SACK blocks can be attached by the receiver to the segments that it sends. SACK blocks allow a TCP receiver to indicate the blocks of data that it has received correctly but out of sequence. The figure below illustrates the utilization of the SACK blocks. 904/10000 · 904
160 ../../protocols/tcp.rst:529
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — TCP selective acknowledgments 29/10000 · 29
161 ../../protocols/tcp.rst:531
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — A SACK option contains one or more blocks. A block corresponds to all the sequence numbers between the `left edge` and the `right edge` of the block. The two edges of the block are encoded as 32 bit numbers (the same size as the TCP sequence number) in an SACK option. As the SACK option contains one byte to encode its type and one byte for its length, a SACK option containing `b` blocks is encoded as a sequence of :math:`2+8 \times b` bytes. In practice, the size of the SACK option can be problematic as the optional TCP header extension cannot be longer than 40 bytes. As the SACK option is usually combined with the :rfc:`1323` timestamp extension, this implies that a TCP segment cannot usually contain more than three SACK blocks. This limitation implies that a TCP receiver cannot always place in the SACK option that it sends, information about all the received blocks. 880/10000 · 880
162 ../../protocols/tcp.rst:533
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — To deal with the limited size of the SACK option, a TCP receiver currently having more than 3 blocks inside its receiving buffer must select the blocks to place in the SACK option. A good heuristic is to put in the SACK option the blocks that have most recently changed, as the sender is likely to be already aware of the older blocks. 335/10000 · 335
163 ../../protocols/tcp.rst:535
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — When a sender receives a SACK option indicating a new block and thus a new possible segment loss, it usually does not retransmit the missing segments immediately. To deal with reordering, a TCP sender can use a heuristic similar to `fast retransmit` by retransmitting a gap only once it has received three SACK options indicating this gap. It should be noted that the SACK option does not supersede the `acknowledgment number` of the TCP header. A TCP sender can only remove data from its sending buffer once they have been acknowledged by TCP's cumulative acknowledgments. This design was chosen for two reasons. First, it allows the receiver to discard parts of its receiving buffer when it is running out of memory without loosing data. Second, as the SACK option is not transmitted reliably, the cumulative acknowledgments are still required to deal with losses of `ACK` segments carrying only SACK information. Thus, the SACK option only serves as a hint to allow the sender to optimize its retransmissions. 1012/10000 · 1012
164 ../../protocols/tcp.rst:537
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — As explained earlier, the TCP Timestamp option :rfc:`1323` prevents ambiguities while collecting round-trip-time measurements. It plays another very important role in today's high-bandwidth networks. Since TCP uses 32 bits long sequence numbers, the sequence numbers wrap after the transmission of 4 GBytes of data. With 10 Gbps and soon 100 Gbps interfaces, TCP only needs to transmit during a few seconds before reusing the same sequence number. Given that the Maximum Segment Lifetime is still 2 minutes, several packets, belonging to the same TCP connection could use the same sequence number. If one of these packets is severely delayed through the network, it could reappear at the same time as a packet with the same TCP sequence number. To prevent this problem, most modern TCP implementations associate a TCP timestamp option to each segment on transmission. When a TCP stack receives a TCP segment, it checks that its TCP timestamp is valid and if not the segment is discarded :rfc:`7323`. 999/10000 · 999
165 ../../protocols/tcp.rst:544
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — TCP connection release 22/10000 · 22
166 ../../protocols/tcp.rst:548
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — TCP, like most connection-oriented transport protocols, supports two types of connection releases : 99/10000 · 99
167 ../../protocols/tcp.rst:550
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — graceful connection release, where each TCP user can release its own direction of data transfer after having transmitted all data 129/10000 · 129
168 ../../protocols/tcp.rst:551
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — abrupt connection release, where either one user closes both directions of data transfer or one TCP entity is forced to close the connection (e.g., because the remote host does not reply anymore or due to lack of resources) 223/10000 · 223
169 ../../protocols/tcp.rst:555
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The abrupt connection release mechanism is very simple and relies on a single segment having the `RST` bit set. A TCP segment containing the `RST` bit can be sent for the following reasons : 190/10000 · 190
170 ../../protocols/tcp.rst:557
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — a non-`SYN` segment was received for a non-existing TCP connection :rfc:`793` 77/10000 · 77
171 ../../protocols/tcp.rst:558
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — by extension, some implementations respond with an `RST` segment to a segment that is received on an existing connection but with an invalid header :rfc:`3360`. This causes the corresponding connection to be closed and has caused security attacks :rfc:`4953` 258/10000 · 258