Prevent large datagrams from blocking the send queue about quic-go HOT 3 CLOSED

#4145 is a proposal for how the SendDatagram will look like with context.

from quic-go.

How do other datagram APIs deal with this? For example, WebTransport has an API to send datagrams. They must be running into the same issue.

One option would be to return a ErrDatagramTooLarge error. However, one reason for the bad datagram performance we're currently suffering from (#3766) is that every call to SendDatagram waits until the datagram has been packaged. The fix for that seems easy: just have a queue of datagrams, allowing more datagrams to be queued, so we can efficiently send them out. However, this also means that we won't be able to return a separate error per call to SendDatagram.

from quic-go.

Looking at https://www.w3.org/TR/webtransport/#example-fixed-rate, WebTransport API provides an option for the caller to wait till the transport is ready. Perhaps SendDatagram can return an error channel of size 1 if we move to a queue of datagrams. That way the caller can decide if they want to wait for the feedback.
However, I think improving performance can be tackle separately. In the meantime to prevent large datagrams from blocking the queue, we can:

• Reject datagrams larger than current MTU. MTU is unlikely to increase in the near future
• For datagrams size less than MTU but larger than the remaining size of the QUIC packet, drop it if it cannot be sent after a few retries

from quic-go.