Bugzilla – Bug 2653
Packet reordering leads to a wrong timestamp saved
Last modified: 2017-12-13 13:06:42 UTC
We currently save the timestamp received in this way: void TcpSocketBase::ProcessOptionTimestamp (const Ptr<const TcpOption> option, const SequenceNumber32 &seq) { NS_LOG_FUNCTION (this << option); Ptr<const TcpOptionTS> ts = DynamicCast<const TcpOptionTS> (option); m_tcb->m_rcvTimestampValue = ts->GetTimestamp (); m_tcb->m_rcvTimestampEchoReply = ts->GetEcho (); ... The function is called regardless of the sequence number of the segment. It means that, if there is a reordering in the network, then we could end up saving a wrong timestamp, instead of the most recent one. This behaviour should be checked also in the ledbat implementation. As steps, I suggest to do the following: * Create a test case in which the error model reorders the packets * Check the timestamp saved and echoed back * Check if the behaviour is consistent with https://tools.ietf.org/html/rfc7323#section-3.1
With the current implementation of ErrorChannel, implementing a test where packets needs to be reordered is a matter of calling ErrorChannel::SetJumpingMode.
Created attachment 2917 [details] patch to not save smaller timestamp This avoids to save smaller timestamps; however, a test case is still missing
fixed in changeset 13213:ce31dcaf0e58