Bugzilla – Bug 2973
Missing RTT measurement due to Retransmission Timeout
Last modified: 2018-08-20 03:28:53 EDT
Summary: In tcp-socket-base.cc's EstimateRtt() function, the RTT measurement is not logged when a retransmission timeout (RTO) occurs. This happens because a RTO will clear m_history (done in ReTxTimeout() function), which contains the list of unacked TCP sequence numbers and their sent timestamp. The sender, correctly, restarts the sequence number and resends the segment associated with the head of m_history. The ACK the sender receives acknowledges not only the retransmitted segment, but also all the segments in the cleared m_history. However, the RTT is not logged because m_history was cleared and now contains new sequence numbers greater than or equal to the ACK number. See log.pdf for an example. In log.pdf, the contents of m_history are printed whenever EstimateRTT() is called. Also, the variable m (which is the measured RTT) is printed (e.g. RTT 246). See tcp-socket-base-EstimateRTT.cc for how I generate the log file.
Created attachment 3159 [details] TCP Log Output PDF is too big, attaching as link.
Created attachment 3160 [details] This is how I output m_history and RTT.
https://tools.ietf.org/html/rfc6298 3. Taking RTT Samples TCP MUST use Karn's algorithm [KP87] for taking RTT samples. That is, RTT samples MUST NOT be made using segments that were retransmitted (and thus for which it is ambiguous whether the reply was for the first instance of the packet or a later instance). The only case when TCP can safely take RTT samples from retransmitted segments is when the TCP timestamp option [JBB92] is employed, since the timestamp option removes the ambiguity regarding which instance of the data segment triggered the acknowledgment. We intentionally do not take RTT from a retransmitted segment. However, as you can read, that is possible when using the timestamp option, even if I don't know what the RTT of a retransmitted segment is. Patch welcome, and this is a feature request, not a bug report.