The SRTO_LOSSMAXTTL option sets the maximum value of reorder tolerance, which when >0 delays sending the lossreport by given number of packets to be first received after the lost one. The problem might be when the packet was really lost (not just reordered), the reorder tolerance is currently 2 and there was just one packet received after the lost one and the sender temporarily doesn't send any packets - in this case the packet will be lost forever due to TLPKTDROP, or received with a virtually infinite delay due to waiting for the "next packet".
The situation when the source has no need to send anything for a long time is signalized by UMSG_KEEPALIVE. This should be the signal that no more packets are going to be delivered for the time being and therefore all packets that are recorded for belated lossreport shall be requested immediately and the reorder tolerance should be reset to 0. That's the least to be done for correctness, although some time-based trigger for sending belated lossreport despite not achieved reorder tolerance might be needed, too.
The SRTO_LOSSMAXTTL option sets the maximum value of reorder tolerance, which when >0 delays sending the lossreport by given number of packets to be first received after the lost one. The problem might be when the packet was really lost (not just reordered), the reorder tolerance is currently 2 and there was just one packet received after the lost one and the sender temporarily doesn't send any packets - in this case the packet will be lost forever due to TLPKTDROP, or received with a virtually infinite delay due to waiting for the "next packet".
The situation when the source has no need to send anything for a long time is signalized by UMSG_KEEPALIVE. This should be the signal that no more packets are going to be delivered for the time being and therefore all packets that are recorded for belated lossreport shall be requested immediately and the reorder tolerance should be reset to 0. That's the least to be done for correctness, although some time-based trigger for sending belated lossreport despite not achieved reorder tolerance might be needed, too.