Draft: draft-ietf-quic-transport

Commentary: Changes to explain Padding = = PADDING Frame 
 Thanks again  . 
 I have a long comment on a scattered observation that could be very simple to fix : In section 6 , it was n’t clear what were the ways that " padding " could be performed . There could be various ways - simply leave UDP payload unused , fill it with coalesced QUIC packets , add padding and other frames , etc and when the text says this I think it ’s unclear to me what is expected - any or all of these , but it does n't seem to be said . e.g. : /Clients that support multiple QUIC versions SHOULD pad the first UDP datagram they send to the largest of the minimum datagram sizes from all versions they support . / Is the assumption here , more like : /Clients that support multiple QUIC versions SHOULD coalesce QUIC packets or add PADDING frames to pad the first UDP datagram they send to the largest of the minimum datagram sizes from all versions they support . / … rather than some other technique to pad - out the datagram payload ? See also : /Clients MUST ensure that UDP datagrams containing Initial packets have UDP payloads of at least 1200 bytes , adding padding to packets in the datagram as necessary . A client that sends padded datagrams allows the server to send more data prior to completing address validation./ and later : /In particular , an endpoint can pad a packet carrying a PATH_CHALLENGE for Path Maximum Transfer Unit ( PMTU ) discovery / So , I think the topic of padding needs a tiny bit more clarification - it ’s almost there , but maybe a sentence that explicitly explains the permitted options in section 14 would be good , which could be cited rather than this scattered mention of “ pad - out ” 
 Perhaps these mentions of the word " padding " just need to reference section 19.1 . " PADDING Frames " ? 
 Yes a REF is good : If that is all that is intended , we should say so . 
 Agreed , I think the right phrasing is PADDING Frames , though I do n't think we need to reference 19.1 in every spot we talk about PADDING frames . 
 So could we grep for Padding and ensure we say /PADDING Frame/ ? - I guess the REF first time used would be good - if not already there ? 
 How about something like : PR ? 
 Closing now that we have . 
 The commas for parentheticals got a little awkward there . Otherwise , this is a good change . I've done a bit of editorializing , and this LGTM . should take a look .
Paragraph (version A):
The size of the first packet sent by a client will determine whether
a server sends a Version Negotiation packet.  Clients that support
multiple QUIC versions SHOULD pad the first UDP datagram they send to
the largest of the minimum datagram sizes from all versions they
support.  This ensures that the server responds if there is a
mutually supported version.  A server might not send a Version
Negotiation packet if the datagram it receives is smaller than the
minimum size specified in a different version; see initial-size.
Paragraph (version B):
The size of the first packet sent by a client will determine whether
a server sends a Version Negotiation packet.  Clients that support
multiple QUIC versions SHOULD ensure that the first UDP datagram they
send is sized to the largest of the minimum datagram sizes from all
versions they support, using PADDING frames (frame-padding) as
necessary.  This ensures that the server responds if there is a
mutually supported version.  A server might not send a Version
Negotiation packet if the datagram it receives is smaller than the
minimum size specified in a different version; see initial-size.
Paragraph (version A):
Clients MUST ensure that UDP datagrams containing Initial packets
have UDP payloads of at least 1200 bytes, adding padding to packets
in the datagram as necessary.  A client that sends padded datagrams
allows the server to send more data prior to completing address
validation.
Paragraph (version B):
Clients MUST ensure that UDP datagrams containing Initial packets
have UDP payloads of at least 1200 bytes, adding PADDING frames as
necessary.  A client that sends padded datagrams allows the server to
send more data prior to completing address validation.
Paragraph (version A):
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.
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 ensure that all packets it sends are at least 22
bytes longer than the minimum connection ID length that it requests
the peer to include in its packets, adding PADDING frames as
necessary.  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.