Draft: draft-ietf-quic-transport

Commentary: 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 is n'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 do n't quite understand how this text works because I do n'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 ca n'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 .
Paragraph (version A):
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.
Paragraph (version B):
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.