Bug 2973

Summary:	Missing RTT measurement due to Retransmission Timeout
Product:	ns-3	Reporter:	Jonah Ho <ho.jonah>
Component:	tcp	Assignee:	natale.patriciello
Status:	PATCH WANTED ---
Severity:	enhancement	CC:	ho.jonah, ns-bugs
Priority:	P3
Version:	ns-3.28
Hardware:	Mac Intel
OS:	Mac OS
Attachments:	TCP Log Output This is how I output m_history and RTT.

Description Jonah Ho 2018-08-19 15:50:48 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.

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

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.