Strategies for handling NACK packet

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.

Read more here: Source link