Re: [quicwg/base-drafts] Clarify initial UDP datagram padding (#2519)

[Martin Thomson <[e-mail]>]

tl;dr: we should always pad to 1200 for UDP datagrams that contain Initial packets.

The reason we pad to 1200 is to provide a server with plenty of inbound bytes so that it can send outbound bytes prior to path validation.  Padding to 1200 has sub-optimal performance in certain cases.  In particular, it makes datagrams containing a simple ACK enormous.  So the original thought was to try to find a case where we could allow for smaller datagrams to be sent.

I think that in both alternative designs we have a problem with the interaction with our DoS defense.  And while those problems might only exist in the abstract for now, I think that the best answer is to pad to 1200 always.

(I will suggest rewording the text separately.)

### Details

An ACK-only Initial packet is sent at the tail of the Initial phase.  That is the obvious candidate for consideration here.  But there are other cases where small Initial packets might be sent.

The looser requirement @kazuho suggests is less than ideal for HelloRetryRequest.  A client can receive a HelloRetryRequest and be forced to send another ClientHello.  We can't assume here that the server is using the HelloRetryRequest to validate the client address (though it certainly can).  

If the ClientHello message is small, the number of bytes that a server can send is still limited.  If the client doesn't pad, the server can still count the original ClientHello toward its budget, but it doesn't get significant additional budget from the client.  And that budget doesn't increase when packets are lost.  So it could be that the server is stuck with 3x whatever it gets in ACKs, which is not a lot.

It's worse if you consider the possibility of the ServerHello being enormous (hello PQ crypto). At this point, the server won't have validated the client address and so is still limited in what it can send.  Ideally, we want the packets to be big so that the server gets more budget for sending and isn't limited to sending tiny packets.  But if all the client sends is small ACK-only packets (under either proposed amendment, either what @ianswett or @kazuho describe), the increased allowance is very small. 

Based on this, I would suggest that we reluctantly say that all Initial-carrying datagrams need to be 1200 bytes or more.

For the case of the ACK at the tail, most of the designs proposed for key discard will result in that packet not being sent.  If it is sent, there are plenty of cases where it will be a packet with Initial (ACK), Handshake (ACK + ...Finished) and 1-RTT data, so the requirement is met without wasting bytes at all.  But for ACK of big ServerHello messages or HelloRetryRequest, the overhead is regrettably necessary.

-- 
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/2519#issuecomment-472671420