Bug 2973 - Missing RTT measurement due to Retransmission Timeout
Missing RTT measurement due to Retransmission Timeout
Product: ns-3
Classification: Unclassified
Component: tcp
Mac Intel Mac OS
: P3 enhancement
Assigned To: natale.patriciello
Depends on:
  Show dependency treegraph
Reported: 2018-08-19 15:50 EDT by Jonah Ho
Modified: 2018-08-20 03:28 EDT (History)
2 users (show)

See Also:

TCP Log Output (25 bytes, text/plain)
2018-08-19 15:53 EDT, Jonah Ho
This is how I output m_history and RTT. (2.69 KB, text/plain)
2018-08-19 15:54 EDT, Jonah Ho

Note You need to log in before you can comment on or make changes to this bug.
Description Jonah Ho 2018-08-19 15:50:48 EDT
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.
Comment 1 Jonah Ho 2018-08-19 15:53:32 EDT
Created attachment 3159 [details]
TCP Log Output

PDF is too big, attaching as link.
Comment 2 Jonah Ho 2018-08-19 15:54:47 EDT
Created attachment 3160 [details]
This is how I output m_history and RTT.
Comment 3 natale.patriciello 2018-08-20 03:28:53 EDT

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.