[BUG] LOSSMAXTTL not working as expected

[skureal]

Hi team,

unfortunately I spotted an unexpected, reproducible behavior with re-ordered packets.
Although LOSSMAXTTL was set to 5 or higher, the SRT receiver triggeres LOSSREPORT control packets at once, even with just a single packet re-ordered in sequence.

The attached picture and table below shows a part of a capture received with srt-xtransmit v0.3.0 dev using SRT library v1.5.5 clock CXX11_STEADY and LOSSMAXTTL=5.

Time	Source	Destination	Length	SRT SeqNo	Msg Type
33.6611004	52.59.196.92	10.90.0.12	1374	606251102
33.661111	52.59.196.92	10.90.0.12	1374	606251103
33.6611221	52.59.196.92	10.90.0.12	1374	606251105
33.6611401	10.90.0.12	52.59.196.92	62		LOSSREPORT
33.6611432	52.59.196.92	10.90.0.12	1374	606251104
33.6611538	52.59.196.92	10.90.0.12	998	606251106
33.664694	52.59.196.92	10.90.0.12	62		ACKACK
33.6668895	52.59.196.92	10.90.0.12	1374	606251104
33.686634	10.90.0.12	52.59.196.92	86		ACK
33.692331	52.59.196.92	10.90.0.12	62		ACKACK
33.6931693	52.59.196.92	10.90.0.12	1186	606251107
33.6931693	52.59.196.92	10.90.0.12	434	606251108

The LOSSREPORT for packet 606251104 should not have been triggered with LOSSMAXTTL=5, as it arrived just "one packet later". Every single re-ordered packet shows exactly this behavior of firing a LOSSREPORT at once.

A cross check with Multi-Streamer v1.8.0 with LOSSMAXTTL=5 setting showed the same behavior. All tests were performed on a Windows 11 machine.

Is the Reorder Tolerance functionality provided by LOSSMAXTTL broken? Or de we miss something here in our setup?

Please let me know, if you need more information.
With best regards,
Justus

[ethouris]

Ok, do you take into account the intended behavior of this option? LOSSMAXTTL has the value of the MAXIMUM stretching the reorder tolerance and the actual reorder tolerance is taken from "experience", that is, at least one reordered packet must be received so that this value is updated. Then with a large enough number of packets coming in order, this value is systematically decreased down to 0, until interrupted or refreshed by another reordered packet.

I understand this may be unwanted behavior; frankly I was suspecting this reordering problem to influence superfluous loss reports and this feature was provided to suppress unnecessary retransmissions, but such an environment where packet reordering can often happen are rare, especially in cable networks, and might be that the solution doesn't solve all its problems. So, this feature was rather introduced as partially experimental, but then we'll be glad if someone can show how useful this is and what it could do to make it function better.

Such a thing as "fixed reorder tolerance" is possible to implement, just I wouldn't like to do this because an increased reorder tolerance means always less time to recover the lost packet. That's the balance of several factors.