Srt: Determine latency and oheadbw value depending on the network loss

[prabh13singh]

Hi there,
I know we can recover from packet loss in network using latency and overhead bandwidth but how do we know that there is loss in network at certain time and there is no loss otherwise and then set the latency/oheadbw accordingly. If we set the latency manually, it can be too low or high depending upon network loss. Is there a mechanism in SRT to check loss continuously?

[jeandube]

It is easy to check loss continuously, just get the stats while streaming. But what you cannot do is change latency or overhead while connected. Changing latency while streaming without affecting a live stream is challenging. If it was permitted by the API it would need to be applied in small increments from the current to the new latency and nothing like this is implemented.

[prabh13singh]

So, will my current srt application lose the packets if the network is good at the beginning and say after 5 minutes, loss start varying from 5% to 10%?
To solve it , I have to implement in API how to change the latency slowly with varying stats, right?

[jeandube]

Latency is agreed upon in the handshake and must be in sync in both peers. The easiest way to do it is to disconnect, reconfigure and reconnect. This is disruptive but if you want to reconfigure live it is because your current setting already cause disruptions. Note that your tests with netem are far from real life condition sine netem can drop packets in absence of congestion. In real life congestion causes all sort of things before dropping packets such as varying RTT, buffer accumulation, etc.

[prabh13singh]

I think you are right about latency. So, do you mean SRT can tolerate expected real-life loss in network but we can't see/test srt for loss with emulated real-life like conditions?

[jeandube]

Netem helps a lot with experimentation but if you want to make changes to the protocol, it shall be tested in real-life conditions. Specially if you base your algorithm on the SRT statistics. For example in your test you rely on UDP to drop corrupted packets to test SRT loss recovering (UDP checksum is optional in IPv4). SRT is content agnostic. netem default random loss is easy for SRT. Congested network losses are more chunky.

[prabh13singh]

We ran it over the Internet. Although, the video was fine, but we still got some packet drops without using latency/oheadbw as it was fine in the starting and then you never know when the network will have any issue.

[prabh13singh]

Hi @jeandube
I have a question regarding your last comment. I was corrupting packets using netem but after receiver, it is showing cc errors at the output. I'm confused here.
How do we rely here on UDP to drop corrupted packets (UDP checksum is optional in IPv4)?

[ethouris]

It is optional, meaning that it is possible that the udp sending facility in the system not calculate it and write 0 in this place; the reader of the packet won't be able to check it. I found this page describing options for that:

https://docs.microsoft.com/en-us/windows/win32/winsock/ipproto-udp-socket-options

There's also an option on the reader side to simply ignore the checksum and deliver packets anyway. If this option is off, corrupted packets should be simply ignored, just like they were lost.

https://linux-tips.com/t/how-to-disable-udp-checksum-control-in-kernel/362

I'm not sure what the default is. I guess the default would be to generate the checksum at the sender and validate it at the receiver - you can experiment with these options though.

[prabh13singh]

But in case of netem(linux), we corrupt them before get calculated by kernel at NIC(by default) and then at reader machine, it will be good and not get dropped.
If we disable it, then it would be passed on as it is and I believe we don't have any checksum implementation in SRT. Am I right?
Has there been any tests on simulating bit-errors and recovering them?