Consider dropping datagrams when congestion occurs

[ryskiwt]

When a large number of datagrams are sent, the datagrams seem to get delayed due to pacing. I am currently developing a delay sensitive application. Dropping datagrams, rather than delaying them, is better suited for such an application.

Does what I wrote above make sense? I don't fully understand the QUIC RFCs, so it may be besides the point. But as far as I've read, RFC9221 says that packets may be dropped when congestion occurs.

5.4. Congestion Control DATAGRAM frames employ the QUIC connection's congestion controller. As a result, a connection might be unable to send a DATAGRAM frame generated by the application until the congestion controller allows it [RFC9002]. The sender MUST either delay sending the frame until the controller allows it or drop the frame without sending it (at which point it MAY notify the application). Implementations that use packet pacing (Section 7.7 of [RFC9002]) can also delay the sending of DATAGRAM frames to maintain consistent packet pacing.

Implementations can optionally support allowing the application to specify a sending expiration time beyond which a congestion-controlled DATAGRAM frame ought to be dropped without transmission.

[Ralith]

Have you played with TransportConfig::datagram_send_buffer_size? When that limit is reached, old unsent outgoing datagrams start getting dropped.

Note that pacing and congestion control are not quite the same mechanism, and pacing alone should not introduce significant delay under reasonable conditions.

[ryskiwt]

Thanks! Your answer is so helpful. I didn't know about the setting. I will try it!!!

[Ralith]

Closing as it seems that the question has been addressed.