|
Bugzilla – Full Text Bug Listing |
| Summary: | Packet reordering leads to a wrong timestamp saved | ||
|---|---|---|---|
| Product: | ns-3 | Reporter: | natale.patriciello |
| Component: | tcp | Assignee: | natale.patriciello |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | adadeepak8, ns-bugs, tahiliani.nitk, tommaso.pecorella |
| Priority: | P3 | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| Attachments: | patch to not save smaller timestamp | ||
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 |
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