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

142 ../../protocols/tcp.rst:426
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — :math:`rttvar=(1-\beta) \times rttvar + \beta \times |srtt - rtt|` 66/10000 · 66
143 ../../protocols/tcp.rst:428
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — :math:`srtt=(1-\alpha) \times srtt + \alpha \times rtt` 55/10000 · 55
144 ../../protocols/tcp.rst:430
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — :math:`rto=srtt + 4 \times rttvar` 34/10000 · 34
145 ../../protocols/tcp.rst:432
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The proposed values for the parameters are :math:`\alpha=\frac{1}{8}` and :math:`\beta=\frac{1}{4}`. This allows a TCP implementation, implemented in the kernel, to perform the `rtt` computation by using shift operations instead of the more costly floating point operations [Jacobson1988]_. The figure below illustrates the computation of the `rto` upon `rtt` changes. 368/10000 · 368
146 ../../protocols/tcp.rst:439
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Example computation of the `rto` 32/10000 · 32
147 ../../protocols/tcp.rst:443
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Advanced retransmission strategies 34/10000 · 34
148 ../../protocols/tcp.rst:447
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The default go-back-n retransmission strategy was defined in :rfc:`793`. When the retransmission timer expires, TCP retransmits the first unacknowledged segment (i.e. the one having sequence number `snd.una`). After each expiration of the retransmission timeout, :rfc:`2988` recommends to double the value of the retransmission timeout. This is called an `exponential backoff`. This doubling of the retransmission timeout after a retransmission was included in TCP to deal with issues such as network/receiver overload and incorrect initial estimations of the retransmission timeout. If the same segment is retransmitted several times, the retransmission timeout is doubled after every retransmission until it reaches a configured maximum. :rfc:`2988` suggests a maximum retransmission timeout of at least 60 seconds. Once the retransmission timeout reaches this configured maximum, the remote host is considered to be unreachable and the TCP connection is closed. 964/10000 · 964
149 ../../protocols/tcp.rst:452
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — This retransmission strategy has been refined based on the experience of using TCP on the Internet. The first refinement was a clarification of the strategy used to send acknowledgments. As TCP uses piggybacking, the easiest and less costly method to send acknowledgments is to place them in the data segments sent in the other direction. However, few application layer protocols exchange data in both directions at the same time and thus this method rarely works. For an application that is sending data segments in one direction only, the remote TCP entity returns empty TCP segments whose only useful information is their acknowledgment number. This may cause a large overhead in wide area network if a pure `ACK` segment is sent in response to each received data segment. Most TCP implementations use a `delayed acknowledgment` strategy. This strategy ensures that piggybacking is used whenever possible, otherwise pure `ACK` segments are sent for every second received data segments when there are no losses. When there are losses or reordering, `ACK` segments are more important for the sender and they are sent immediately :rfc:`813` :rfc:`1122`. This strategy relies on a new timer with a short delay (e.g. 50 milliseconds) and one additional flag in the TCB. It can be implemented as follows. 1301/10000 · 1301
150 ../../protocols/tcp.rst:480
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Due to this delayed acknowledgment strategy, during a bulk transfer, a TCP implementation usually acknowledges every second TCP segment received. 145/10000 · 145
151 ../../protocols/tcp.rst:482
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The default go-back-n retransmission strategy used by TCP has the advantage of being simple to implement, in particular on the receiver side, but when there are losses, a go-back-n strategy provides a lower performance than a selective repeat strategy. The TCP developers have designed several extensions to TCP to allow it to use a selective repeat strategy while maintaining backward compatibility with older TCP implementations. These TCP extensions assume that the receiver is able to buffer the segments that it receives out-of-sequence. 542/10000 · 542
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