[core] Extended logs for negative or zero RTT estimate on the receiver side

[mbakholdina]

(1) - This PR provides extended logs for negative or zero RTT estimate on the receiver side, former "IPE: ACK node overwritten message". See issue #253 for details.

The logs are now splitted into two cases:

• When the record about ACK is not found in the buffer,
• When the RTT estimate obtained by the receiver based on ACK/ACKACK pair is negative or zero.

This check happens upon ACKACK reception by the receiver.

The logs format is the following:

12:40:38.677155/SRT:RcvQ:w1*E:SRT.in: @577838857:IPE: The record about ACK is not found, RTT estimate at the receiver side can not be calculated (ACK number: 113, last ACK sent: 115, oldest ACK record: not yet available, RTT (EWMA): 21052)

12:40:38.677194/SRT:RcvQ:w1*E:SRT.in: @577838857:IPE: RTT estimate obtained by the receiver is negative or zero, there may have been a time shift (current time: 18705D 11:40:38.677154 [STDY], the time of sending ACK: not yet available, RTT estimate: 21015). The usage of monotonic clocks is recommended.

(2) - Additionally, the current time of ACKACK packet reception currtime is now passed to the acknowledge function (window.cpp) as an argument to make the RTT estimate calculation more precise.

The change has been tested in the following way.

TODO

• In the first log, oldest ACK record: not yet available.
• In the second log, the time of sending ACK: not yet available. The redesign of acknowledge function (window.cpp) is required to be able to extract this value from the buffer with ACK records.
• Is there a need to rename currtime argument in acknowledge function to something like ACKACKReceptionTime?
• The arguments names seq and ack used in store and acknowledge functions are difficult to read. I would suggest proper renaming: seq -> ACKSeqNo (as per Seq structure, meaning ACK packet Seq. No.), ack -> AckPktSeqNo (meaning acknowledged packet Seq. No.). In the Seq structure the renaming is also required: iACK -> iAckPktSeqNo.
• The function int32_t CPacket::getAckSeqNo() const (packet.cpp) probably needs renaming to int32_t CPacket::getAckPktSeqNo() const.

[maxsharabayko]

TODO

• Provide a way to identify clock type (@maxsharabayko - a separate PR to be created)

[maxsharabayko]

This PR adds reading m_iAckSeqNo in CUDT::processCtrl(..) function.
Another place this variable is accessed is in the CUDT::sendCtrl(..) function.
Both m_iAckSeqNo and m_ACKWindow are not protected from simultaneous access from different threads.
However, both are accessed from the CRcvQueue worker thread. ACK is sent from this thread from checkTimers(..) function.

Therefore, adding m_iAckSeqNo should be ok.