Exit Zen
121
../../protocols/tcp.rst:347
English
8590 Gbps
0/100 · 9
122
../../protocols/tcp.rst:348
English
859 Gbps
0/100 · 8
123
../../protocols/tcp.rst:349
English
86 Gbps
0/100 · 7
124
../../protocols/tcp.rst:350
English
17 Gbps
0/100 · 7
125
../../protocols/tcp.rst:357
English
These throughputs are acceptable in today's networks. However, there are already servers having 10 Gbps interfaces... Early TCP implementations had fixed receiving and sending buffers [#ftcphosts]_. Today's high performance implementations are able to automatically adjust the size of the sending and receiving buffer to better support high bandwidth flows [SMM1998]_.
0/3680 · 368
126
../../protocols/tcp.rst:362
English
TCP's retransmission timeout
0/280 · 28
127
../../protocols/tcp.rst:364
English
In a go-back-n transport protocol such as TCP, the retransmission timeout must be correctly set in order to achieve good performance. On one hand, if the retransmission timeout expires too early, then bandwidth is wasted by retransmitting segments that have already been correctly received. On the other hand, if the retransmission timeout expires too late, then bandwidth is wasted because the sender is idle waiting for the expiration of its retransmission timeout.
0/4670 · 467
128
../../protocols/tcp.rst:366
English
A good setting of the retransmission timeout clearly depends on an accurate estimation of the round-trip-time of each TCP connection. The round-trip-time differs between TCP connections, but may also change during the lifetime of a single connection. For example, the figure below shows the evolution of the round-trip-time between two hosts during a period of 45 seconds.
0/3730 · 373
129
../../protocols/tcp.rst:372
English
Evolution of the round-trip-time between two hosts
0/500 · 50
130
../../protocols/tcp.rst:375
English
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.
0/3010 · 301
131
../../protocols/tcp.rst:381
English
How to measure the round-trip-time ?
0/360 · 36
132
../../protocols/tcp.rst:388
English
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.
0/5140 · 514
133
../../protocols/tcp.rst:394
English
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.
0/7360 · 736
134
../../protocols/tcp.rst:400
English
Disambiguating round-trip-time measurements with the :rfc:`1323` timestamp option
0/810 · 81
135
../../protocols/tcp.rst:402
English
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`.
0/4980 · 498
136
../../protocols/tcp.rst:404
English
The original TCP specification proposed in :rfc:`793` to include two additional variables in the TCB :
0/1020 · 102
137
../../protocols/tcp.rst:406
English
`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)
0/2470 · 247
138
../../protocols/tcp.rst:407
English
`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.
0/3030 · 303
139
../../protocols/tcp.rst:409
English
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`.
0/4300 · 430
140
../../protocols/tcp.rst:411
English
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 :
0/3610 · 361