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

130 ../../protocols/tcp.rst:375
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The easiest solution to measure the round-trip-time on a TCP connection is to measure the delay between the transmission of a data segment and the reception of a corresponding acknowledgment [#frttmes]_. As illustrated in the figure below, this measurement works well when there are no segment losses. 301/10000 · 301
131 ../../protocols/tcp.rst:381
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — How to measure the round-trip-time ? 36/10000 · 36
132 ../../protocols/tcp.rst:388
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — However, when a data segment is lost, as illustrated in the bottom part of the figure, the measurement is ambiguous as the sender cannot determine whether the received acknowledgment was triggered by the first transmission of segment `123` or its retransmission. Using incorrect round-trip-time estimations could lead to incorrect values of the retransmission timeout. For this reason, Phil Karn and Craig Partridge proposed, in [KP91]_, to ignore the round-trip-time measurements performed during retransmissions. 514/10000 · 514
133 ../../protocols/tcp.rst:394
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — To avoid this ambiguity in the estimation of the round-trip-time when segments are retransmitted, recent TCP implementations rely on the `timestamp option` defined in :rfc:`1323`. This option allows a TCP sender to place two 32 bit timestamps in each TCP segment that it sends. The first timestamp, TS Value (`TSval`) is chosen by the sender of the segment. It could for example be the current value of its real-time clock [#ftimestamp]_. The second value, TS Echo Reply (`TSecr`), is the last `TSval` that was received from the remote host and stored in the :term:`TCB`. The figure below shows how the utilization of this timestamp option allows for the disambiguation of the round-trip-time measurement when there are retransmissions. 736/10000 · 736
134 ../../protocols/tcp.rst:400
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Disambiguating round-trip-time measurements with the :rfc:`1323` timestamp option 81/10000 · 81
135 ../../protocols/tcp.rst:402
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Once the round-trip-time measurements have been collected for a given TCP connection, the TCP entity must compute the retransmission timeout. As the round-trip-time measurements may change during the lifetime of a connection, the retransmission timeout may also change. At the beginning of a connection [#ftcbtouch]_, the TCP entity that sends a `SYN` segment does not know the round-trip-time to reach the remote host and the initial retransmission timeout is usually set to 3 seconds :rfc:`2988`. 498/10000 · 498
136 ../../protocols/tcp.rst:404
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The original TCP specification proposed in :rfc:`793` to include two additional variables in the TCB : 102/10000 · 102
137 ../../protocols/tcp.rst:406
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `srtt` : the smoothed round-trip-time computed as :math:`srtt=(\alpha \times srtt)+( (1-\alpha) \times rtt)` where :math:`rtt` is the round-trip-time measured according to the above procedure and :math:`\alpha` a smoothing factor (e.g. 0.8 or 0.9) 247/10000 · 247
138 ../../protocols/tcp.rst:407
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `rto` : the retransmission timeout is computed as :math:`rto=\min(60,max(1,\beta \times srtt))` where :math:`\beta` is used to take into account the delay variance (value : 1.3 to 2.0). The `60` and `1` constants are used to ensure that the `rto` is not larger than one minute nor smaller than 1 second. 303/10000 · 303
139 ../../protocols/tcp.rst:409
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — However, in practice, this computation for the retransmission timeout did not work well. The main problem was that the computed `rto` did not correctly take into account the variations in the measured round-trip-time. `Van Jacobson` proposed in his seminal paper [Jacobson1988]_ an improved algorithm to compute the `rto` and implemented it in the BSD Unix distribution. This algorithm is now part of the TCP standard :rfc:`2988`. 430/10000 · 430
140 ../../protocols/tcp.rst:411
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Jacobson's algorithm uses two state variables, `srtt` the smoothed `rtt` and `rttvar` the estimation of the variance of the `rtt` and two parameters : :math:`\alpha` and :math:`\beta`. When a TCP connection starts, the first `rto` is set to `3` seconds. When a first estimation of the `rtt` is available, the `srtt`, `rttvar` and `rto` are computed as follows : 361/10000 · 361
141 ../../protocols/tcp.rst:424
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Then, when other rtt measurements are collected, `srtt` and `rttvar` are updated as follows : 93/10000 · 93
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