HackMD
RTO 機制
The Transmission Control Protocol (TCP) uses a retransmission
timer to ensure data delivery in the absence of any feedback from the
remote data receiver.
參考: rfc793, rfc6298 , Congestion Avoidance and Control
在 TCP 通訊進行中雙方會存在需要等待對方回應時間。此段時間的大小存在許多因素像是網路環境，對方主機狀況…。而在 TCP 存在重新傳送機制，那此時就有個問題了：多久的時間沒有收到 TCP ACK 將會看作需要重新重算呢？
RTO 計算
a TCP sender maintains two state
variables, SRTT (smoothed round-trip time) and RTTVAR (round-trip
time variation).
The Basic Algorithm
- RTT 簡而言之就是 Sender 送出一個 TCP 封包後，計算送出與收到 TCP ACK 回應的時間差。
在通訊雙方建立TCP連線後，初始的RTO應該設定為 < 1的值。(當然存在許多例外，但是會建議小的初始值)
Until a round-trip time (RTT) measurement has been made for a segment sent between the sender and receiver, the sender SHOULD set RTO <- 1 second, though the "backing off" on repeated retransmission discussed in (5.5) still applies.
Note that the previous version of this document used an initial RTO of 3 seconds. A TCP implementation MAY still use this value (or any other value > 1 second). This change in the lower bound on the initial RTO is discussed in further detail in Appendix A.
- 當得到第一個 RTT 後，系統會得到第一個 SRTT 以及 RTTVAR 值。
(clock granularity = G seconds)
SRTT = RTT
RTTVAR = R/2
RTO = SRTT + (G, K*RTTVAR) where K = 4.
When the first RTT measurement R is made, the host MUST set
SRTT <- R
RTTVAR <- R/2
RTO <- SRTT + max (G, K*RTTVAR) where K = 4.
- 之後，雙方又進行一次傳輸，得到第二個 RTT = R' sec，系統先會更新RTTVAR 以及 SRTT，此時候先更新 RTTVAR，當下使用為舊的 SRTT。
RTTVAR = (1 - beta) * RTTVAR + beta * |SRTT - R'|
SRTT = (1 - alpha) * SRTT + alpha * R'
在得到結果後便可以更新RTO。
RTO = SRTT + max (G, K*RTTVAR)
When a subsequent RTT measurement R' is made, a host MUST set
RTTVAR <- (1 - beta) * RTTVAR + beta * |SRTT - R'|
SRTT <- (1 - alpha) * SRTT + alpha * R'
The value of SRTT used in the update to RTTVAR is its value before updating SRTT itself using the second assignment. That is, updating RTTVAR and SRTT MUST be computed in the above order. The above SHOULD be computed using alpha=1/8 and beta=1/4 (as suggested in [JK88]). After the computation, a host MUST update RTO <- SRTT + max (G, K*RTTVAR)
- 若 RTO 小於 1 秒，則會取 1 秒的值。
Whenever RTO is computed, if it is less than 1 second, then the RTO SHOULD be rounded up to 1 second.
Traditionally, TCP implementations use coarse grain clocks to measure the RTT and trigger the RTO, which imposes a large minimum value on the RTO. Research suggests that a large minimum RTO is needed to keep TCP conservative and avoid spurious retransmissions [AP99]. Therefore, this specification requires a large minimum RTO as a conservative approach, whileat the same time acknowledging that at some future point, research may show that a smaller minimum RTO is acceptable or superior.
- A maximum value MAY be placed on RTO provided it is at least 60 seconds.
RTT取樣
Clock Granularity
稍早提到的 G 值，代表硬體的時間精度，通常不會有硬性規範，照個平台使用。
為何建議使用較小的 RTO 初始值？
RTO 需要考慮以下兩項平衡點
- 足夠大以應付通訊雙方所需要傳輸時間。
- The initial RTO should be sufficiently large to cover most of the
end-to-end paths to avoid spurious retransmissions and their
associated negative performance impact.
- 足夠小以減少不必要的 ACK 封包等待時間
- The initial RTO should be small enough to ensure a timely recovery
from packet loss occurring before an RTT sample is taken.
過去大多採用 3 秒的重傳時間 rfc1122，在 rfc6298 中會建議草用 1 秒的初始 RTO ，詳細原因可以參考連結，主要為經過統計結果以及現在網路速度的提升。
