Sensitivity of SRTO_SNDDROPDELAY

[kavyarav]

Hi,
I am trying to use SRT (1.4.1) live mode with the following settings:
SRTO_LATENCY - 700 ms
SRTO_SNDSYN - false
SRTO_SNDDROPDELAY - 2000 ms (have tried many lower values)
SRTO_CONNTIMEO - 5 seconds
When I run a video transmission and use traffic shaping with delay of 10ms, 2% packet loss and 12mbit bitrate, I see several packets dropped in the sender side. My transmission is around 4 mb/s. I tried several other settings for the traffic shaping, any setting with even a minute delay causes a lot of packets to be dropped.

E:SRT.d: SND-DROPPED 2 packets - lost delaying for 2162ms

E:SRT.d: SND-DROPPED 2 packets - lost delaying for 2201ms

E:SRT.d: SND-DROPPED 2 packets - lost delaying for 2200ms

E:SRT.d: SND-DROPPED 2 packets - lost delaying for 2201ms

I am not sure what is causing data to be backing up so much. Is it caused due to congestion control algorithms? If so, how can I make amends to make sure my transmission works better with poor networking conditions. Is there any settings you'd suggest? Thanks a lot!

[maxsharabayko]

Hi @kavyarav
What is the RTT of your link? You said you use "traffic shaping with delay of 10ms", I assume you are testing on some local switch with minimum RTT then?

[kavyarav]

Hi @maxsharabayko,
I am running server and client both on my laptop. As for traffic shaping I use tc
tc qdisc add dev mynet root netem delay 10ms 10ms loss 2% rate 12mbit

(even setting to 1ms delay produces same packet drop behavior)
The RTT reported by SRT starts off with:
Network stats: Bandwidth=14.34 RTT=0.092 Sent=12580 Dropped=0 Retrans=0

And when this packet drop starts, SRT reports network stats as:
Network stats: Bandwidth=12.18 RTT=0.081 Sent=21112 Dropped=21112 Retrans=0

Kindly let me know if you need more information.

[maxsharabayko]

@kavyarav Could you collect a network capture of your transmission? With WireShark or tcpdump. Preferably both on the receiving and sending sides. We can then take a look at how packets are transmitted.

[J-Rogmann]

Hi @kavyarav
I would like to follow up on your case. Would it be possible to create a packet capture of your test? It would be best, if the packet capture (wireshark or tcpdump) is started before the SRT connection is started. 30 seconds should be enough to analyse.
Could you also share the command line you used, so I can see all the parameters, that you were using?

Many thanks and best regards,
Justus

[J-Rogmann]

Hello @kavyarav

Do you have any updates on this ticket or can it be closed?
Please let us know, if you need help or how you solved the issue, in case you found the root cause yourself.

best regards,
Justus

[maxsharabayko]

TODO

• Reproduce using srt-xtransmit or srt-live-transmit.

Apply network impairments using tc:

tc qdisc add dev mynet root netem delay 10ms 10ms loss 2% rate 12mbit

SRT configuration:

• SRTO_LATENCY - 700 ms
• SRTO_SNDSYN - false
• SRTO_SNDDROPDELAY - 2000 ms (have tried many lower values)
• SRTO_CONNTIMEO - 5 seconds

Reported link RTT is < 1ms. A local switch can be used.

Expected Behavior

RTT 1ms, latency 700ms, 2% loss and jitter 10ms is not expected to produce any drops, as there is enough latency to recover 2% of lost packets. Jitter with the default SRTO_LOSSMAXTTL will result in at least 4% of retransmission overhead for actually lost packets, and .some additional overhead to retransmission of packets wrongfully detected lost (out of order packets).

[J-Rogmann]

@kavyarav
I reproduced your setup with a 4 Mbps stream through a 12 Mbps pipe with same SRT parameters and haven't seen any pktRcvDrop in statistics.
I had problems with tc qdisc on CentOS and was introducing the loss and jitter with a network impairment device by LANforge.
I'll flip the setup to tc and repeat and let you know about the outcome.
best regards,
Justus

[J-Rogmann]

I performed another test with using netem

tc qdisc add dev enp7s0 root netem delay 10ms 10ms loss 2% rate 12mbit

sender:

srt-xtransmit generate "srt://192.168.4.2:4200?latency=700&blocking=off&snddropdelay=2000&conntimeo=5000" --sendrate 4Mbps --duration 120s --enable-metrics --statsfile group-snd-stats.csv --statsfreq 1s -v

receiver:

srt-xtransmit receive "srt://:4200?latency=700&blocking=off&snddropdelay=2000&conntimeo=5000" --enable-metrics --metricsfile group-rcv-metrics.csv --metricsfreq 1s --statsfile group-rcv-stats.csv --statsfreq 1s -v

I can see pktRcvLoss but not a single pktRcvDrop dropped packet, which is expected.
The test done with network impairment started and also with clean network and kicking in the impairment during transmission.

the only difference I can see: I was using a 1.4.2 SRT library. To repeat that test with your mentioned 1.4.1 lib would take me some time.

@kavyarav: Can you upgrade to a 1.4.2 build? If your error still exists, can you perform a packet capture (started prior to the SRT connection to get the handshake)
I will leave the ticket open for another week.

[maxsharabayko]

SND-DROPPED error message was downgraded to debug-heavy log in #1271, so this message would not be seen normally in the terminal.

@J-Rogmann

I can see pktRcvLoss but not a single pktRcvDrop dropped packet, which is expected.

pktSndDrop might be non-zero. I wonder if you have the archive with tests results to check?

[J-Rogmann]

I double checked and the statistics files show 0 SND-DROPPED packets in my tests. I do see re-transmissions, but no drops from the sender side.
group-snd-stats.xlsx

@kavyarav
Do you have any updates on this case? Did you retry or can you even provide a packet capture, so we can take a closer look?
best regards,
Justus

[mbakholdina]

Closing as Can't Reproduce. Please feel free to reopen the ticket in case of further questions.