Change:
to include at least 38 bits of data (or 5 bytes, less the two fixed bits). <del> A minimum size of 21 bytes does not guarantee that a stateless reset is difficult to distinguish from other packets if the recipient requires the use of a connection ID.  To prevent a resulting stateless reset from being trivially distinguishable from a valid packet, all packets sent by an endpoint SHOULD be padded to at least 22 bytes longer than the minimum connection ID that the endpoint might use.  An endpoint that sends a stateless reset in response to a packet that is 43 bytes or less in length SHOULD send a stateless reset that is one byte shorter than the packet it responds to. </del> <ins> The resulting minimum size of 21 bytes does not guarantee that a stateless reset is difficult to distinguish from other packets if the recipient requires the use of a connection ID.  To achieve that end, the endpoint SHOULD pad all packets it sends to at least 22 bytes longer than the minimum connection ID that it might request the peer to include in packets that the peer sends.  This ensures that any stateless reset sent by the peer is indistinguishable from a valid packet sent to the endpoint.  An endpoint that sends a stateless reset in response to a packet that is 43 bytes or shorter SHOULD send a stateless reset that is one byte shorter than the packet it responds to. </ins> These values assume that the Stateless Reset Token is the same length as the minimum expansion of the packet protection AEAD.  Additional

Discussion:
For stateless resets, we recommend a minimum packet size on ALL packets, based on the maximum length of connection IDs that might be generated by the same endpoint. This isn't exactly clear, but nor do I think we need to include the fully worked logic that leads to it. This attempts to split the difference.
difficult to distinguish from other packets if the recipient requires the use of a connection ID. To prevent a resulting stateless reset from being trivially distinguishable from a valid packet, all packets sent by an endpoint SHOULD be padded to at least 22 bytes longer than the minimum connection ID that the endpoint might use. I don't quite understand how this text works because I don't get to control the CIDs that I send with.
Would this be clearer if it said: ?
I feel like maybe I'm having trouble understanding the reasoning here. Do you mind walking me through it?
The logic is a little turgid and I think we were reluctant to show our working. The sender of a stateless reset can't know how big a connection ID the peer might have requested it use. This makes packets potentially distinguishable a peer wanted the largest connection ID size (20) and the packet size drops below 41 bytes. The sender of a stateless reset is required to reduce packet size for the stateless reset, unless it is counting somehow. So, if an endpoint wants to ensure that a peer can generate an indistinguishable stateless reset, assuming that its peer is following the size reduction rule, and assuming that the reduction is just one byte (because the stateless reset sender also wants it to be indistinguishable), then it needs to send packets of at least 42 bytes in the general case. But if it knows that it would never ever ask for a connection ID larger than N, then it can instead send packets of size N+22 and the goal is accomplished without sending larger packets all the time.