IPE: ACK node overwritten message (impact unknown)

[ethouris]

There's a message appeared in one of tests:

11:54:57.501306/SRT:RcvQ:worker*E: SRT.c: IPE: ACK node overwritten when acknowledging 1979 (ack extracted: 0)

Impact unknown, although this is qualified as IPE, so it shouldn't happen. This was during tests against 1.1.3 version (Makito) and it might come from the other side. Need to make sure that this kind of problem is never CAUSED by the 1.3 version client.

[ethouris]

Further study states that:

1. The implementation of the ACK window - refactored only formally (just in order to avoid dynamic allocation and too fine-grained delocalization) - is messy, although it's meant to be for relatively simple use. It's hard to say the exact reason that ACK node may be overwritten.
2. A probable reason why this happens is that the ACK window is "too short" and the ACKACK response for ACK message has a journal of an ACK message that has been already wiped out the ACK window. Trouble is, the ACK window has set a size of 1024 elements, and this is about having ACKACK response lacking for the whole window, which is either that the ACKACK response isn't being sent (seems impossible) or lost on track (as larger packets are more probable to be lost, and data packets are not being lost, very hardly possible), or there's some unknown internal implementation problem.
3. The only impact of this event is that the RTT, which is measured as a distance in time between the moment when this ACK message is being sent and when the ACKACK message with the same journal ("ACKNumber") is received, cannot be measured because one of the ingredients for this calculation is missing. RTT is however measured all the time, so losing one opportunity to measure RTT is not a big deal. It would be much worse if such messages appear very often one after another, which means that RTT isn't really being measured, but this isn't the case here.

Research result: minor problem, rather annoying, but it's a developer-uncomfortable situation of an unknown source of problems, even if they are minor.

Recommended: Use some general class of a ring buffer and implement CACKWindow class anew on that base. Important is a possibility to track the running size of the ACK window.

[ethouris]

There should be determined the reason why this node overriding happens. If this isn't anything that influences the overall processing, then the log contents should be changed.

[maxsharabayko]

Message can be seen when netem is applied:

sudo tc qdisc add dev eno1 root netem delay 25ms 10ms loss 4%

SRT default settings with 100 ms latency over a local switch

Note. Delete netem config

sudo tc qdisc del dev eno1 root netem delay 25ms 10ms loss 4%

[ethouris]

When deleting, only the parameters up to root are required.