[quicwg/base-drafts] Padding overhead in DNS over QUIC scenarios (#3523)

[Christian Huitema <[e-mail]>]

I am looking at DNS over QUIC scenarios. A common case would be a resumed session in which the client sends the short DNS query as 0-RTT data, and the server then sends the response after the session is confirmed. Assuming a service delay larger than 1-RTT, I expect to see something like:

1- Client initial + 0-RTT (DNS query), 1232 bytes, including 669 bytes of padding
2- Server Initial + handshake + 1-RTT (Crypto ticket, 2x new connection ID), 606 bytes
3- Handshake (finished) + 1 RTT (2x new connection ID) 222 bytes
4- Server 1RTT(handshake done) 55 bytes
5-Client 1-RTT(ACK) 55 bytes
6- Server 1-RTT (DNS response) 85 bytes

That's 2170 bytes total, of which 31% are the initial padding -- which is also 44% of the client's traffic. That's quite a bit of overhead. The question is, is that strictly necessary? 

Suppose for example that the server also provisions a "NEW TOKEN", maybe 40 bytes long. The server can verify the token when receiving the first packet, and validate the IP address. At that point, the concerns about DDOS are mostly mitigated. We could remove the 669 bytes of padding, at the cost of an initial token (1 byte length, 40 bytes data) and a NEW TOKEN frame (1 byte type, 1 byte length, 40 bytes data), i.e. a gain of 486 bytes. The client would send a total of 923 bytes instead of 1503, the total exchange would use 1584 bytes instead of 2170.

What do you think? Would it be OK to relax the "pad to 1200" rule when the Initial carries a valid token? Should we make that part of the main spec, or treat that as an extension?



-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3523