SRT - spurious retransmissions in Wireshark pcap - has anyone experience of SRT retransmissions on a clean network between two differing implementers of srt ver 1.5.1?

[ronnfenn]

Good evening
I have recently set up a Sender from supplier A to a Receiver of supplier B - back to back - clean network - and on a tried and tested Receiver.... all good except for "spurious" occasional and continual retransmissions - 1 pkt every say 2/3 minutes
Supplier A blames Supplier B so far - I suspect the SRT implementation on ver 1.5.1 may NOT be entirely stable?
Does Buffer mgmt and retransmits timeout counters on my 21Mb encoded video srt flow have anything to do with the observations Ive made?
When asking Bing for pcaps of srt spurious retransmits - Bing was unable to find any...
Plenty of TCP retransmit examples though...
Thanks

[ethouris]

It is not possible that SRT causes any spurious retransmissions by itself.

There are several rules for retransmissions with various settings, but as long as we speak about the default settings in the default live mode, there are only two rules under which retransmissions can be sent:

• when the receiver reports the loss
• when once reported loss was not acknowledged in expected time

(Just for the record: there exists in SRT a mechanism called "blind retransmission", which is something similar to what TCP does - sending all packets since the last ACK, no matter if any of them were really received or not - but it only works in file mode, or in live mode only if you turn off SRTO_NAKREPORT - with default settings this mechanism is not in use).

The first one happens only strictly in one case: when an incoming data packet contains the sequence number that is greater than the previously received one in the previous data packet by more than one. This is possible, at least in theory, to happen even if there are no packets losses, in the following cases:

• when the network link is causing reordering of the UDP packets. This way one packet may be a bit delayed and the next one comes in earlier than this; this will be interpreted by SRT as a loss and SRT will send the loss report. There exists a mechanism to counter this problem (see SRTO_LOSSMAXTTL option), but it's only for quite often happening reordering - it sets the maximum distance between ordered and reordered packets and allows the current reorder distance to grow on detection; loss reports will not be sent as long as the lost sequence isn't grown up to the reorder distance. It also decreases once no reordering is detected. So if you have just one packet per 2 minutes, the reordering happens too sparsely to be detected as permanent and increase the reorder distance.
• allso, at least in theory, in UDP there can happen "phantom packets", that is, one packet once sent earlier can be sent again by one of the routers on the way. It;s one of the phenomena described as theoretically possible in UDP, although hard to say whether it really happens.

Note that if you have a link that behaves this way all the time, it could show different behavior when you record a pcap on the sender and on the receiver. If there is a reordering really happening, you should be able to see that a retransmitted packet (note the R flag, if you see it in Wireshark) should be then received earlier, but the packet that has the sequence number next to it was received earlier. The same series of packets could be seen at the sender side in a perfect order. Similarly, if you can see this packet not as retransmitted (R flag clear), it could be probably not visible at the sender pcap.

[ronnfenn]

Thanks for the prompt response Ethouris! Im a novice in this area - pls find attached the problematic pcap... I think a second opinion from an expert is warranted, pls! I note - pcaps are not a supported upload format - so will 7zip it. sorry exceeds 25Mb limit!
the initial Network setup - initially back to back single copper interconnect - tends to exclude the phantom pkt theory (option 2) I d say.
Thanks