Strategies for handling NACK packet

[Michal Śledź]

HI,

one of the RFCs related to NACK or RTX says that it depends on implementation how NACK are handled - whether packet is retransmitted or not.

In our approach, we have a buffer for last 300 packets and whenever a browser requests for retransmission of a packet that is in our buffer, we fulfill its demand and resend the lost packet.

The problem with such an approach is that sometimes the browser asks for a really big number of packets (300-600). Here is an example raw NACK we receive 

<<82, 48, 255, 255, 82, 65, 255, 255, 82, 82, 255, 255, 82, 99, 255, 255, 82, 116, 255, 255, 82, 133, 255, 255, 82, 150, 255, 255, 82, 167, 255, 255, 82, 184, 255, 255, 82, 201, 255, 255, 82, 218, 255, 255, 82, 235, 255, 255, 82, 252, 255, 255, 83, 13, 255, 255, 83, 30, 255, 255, 83, 47, 255, 255, 83, 64, 255, 255, 83, 81, 255, 255, 83, 98, 255, 255, 83, 115, 255, 255, 83, 132, 255, 255, 83, 149, 255, 255, 83, 166, 255, 255, 83, 183, 255, 255, 83, 200, 255, 255, 83, 217, 255, 255, 83, 234, 255, 255, 83, 251, 255, 255, 84, 12, 255, 255, 84, 29, 255, 255, 84, 46, 255, 255, 84, 63, 1, 255>>

While we could try to retransmit everything we have, it is very unlikely that browser will make any use of those packets. It would also result in bursts of packets in our processing pipeline/socket etc. unless we introduce some kind of pacing.

It's also pretty strange why borwser sends such a big NACK. I would expect it to be able to determine that there is no longer sense in requesting packet with seq num 500 when the expected seq num is 1000. I mean, there is too big gap in the transmission to request the retransmission of seq num 500.

I wonder if you noticed similar size of NACK and what are your strategies for handling NACK packets.

[Philipp Hancke]

such large NACK packets are rather unusual, you might want to check the sequence numbers that you rewrite to.

https://groups.google.com/g/discuss-webrtc/c/gik2VH4hUjk/m/xWUyA_XXAQAJ remains very relevant

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/d59e983e-e78d-4ad6-a6db-9b42a6c76560n%40googlegroups.com.

[Michal Śledź]

Thanks a lot! Will check that

[Michal Śledź]

We are testing with H264 so all things related to VP8 payload header can't be the reason. We will make sure that our RTP munger works correctly - we don't create any gaps in sequence numbers.

But I also wonder if the reason of such behavior might be incorrect timestamps? We generate padding packets for probing the connection and each padding packet has timestamp of the last video frame that we sent. If we send a couple of padding packets in a raw, all of them will get different seq nums but the same timestamp. This for sure impacts jitter calculation (not necessarily avg jitterBufferDelay)...