Open MWedl opened 2 months ago
We are planning work on the padding system that should address this and some other issues. No timeline at the moment though.
@rthalley The more I think about it, the more I find the "pad the datagram, not the packet" approach is the easiest to implement..
What you say about padding the datagram makes sense to me!
First of all, thanks for developing and maintaining this amazing library.
Description
I am trying use the full potential of HTTP/3 and QUIC by utilizing 0-RTT handshakes and inculde early data (HTTP/3 requests) in the 0-RTT handshakes. aioquic sends the Initial packet and 0-RTT packet as two separate UDP datagrams. This means that early data requests are not included in the transmitted datagram.
The problem seems to be how aioquic pads initial packets. aioquic adds PADDING frames to the initial packet. This fills the UDP datagram leaving no space for the 0-RTT packet anymore, which results in the 0-RTT packet being sent in the next datagram.
In order to solve this issue, aioquic should add padding to UDP datagrams instead of QUIC packets. UDP datagrams can be padded by adding zero bytes after all QUIC packets inside a UDP datagram. This UDP datagram padding works for datagrams containing only packets with long headers, because the long header features a length field. This UDP padding is used by other QUIC clients such as Firefox.
Reproducable example