Draft: draft-ietf-quic-transport

Commentary: This is n't a complete dissertation on how clients might choose to use larger packet sizes . In particular , it does n't capture the whole discussion about starting at a higher size being a way to raise the 1280 to something higher , with the requisite cost being that you might have failures . Deciding to put that in would be much harder . What this does is just say that the transport parameter acts as a further limit on packet size and that you wo n't know that prior to knowing . That means that you are guessing about the network path AND your peer when you decide to send 1200 ( to be fair , the former really only applies for IPv4 , and it 's not much of a guess ) . 
 The transport parameter ( formerly known as ) instructs the receiving endpoint that it should try to avoid sending packets bigger than that number . However , some packets are sent before the transport parameters are received . Should the draft contain some guidance about what value to use during the handshake ? Our implementation currently uses a default value of 1350 until the transport parameters have been received , and I wonder if that may lead to interop issues if some Web servers implement QUIC but drop packets larger than 1300 for example . One could consider using the minimum possible value ( 1200 ) during the handshake but I fear that this would negatively impact performance . 
 This is a good issue . If we are to provide guidance , my preference goes to stating that an endpoint should not send datagrams that are larger than its first flight , unless that endpoint implements PMTUD . The rationale is that we should avoid packets starting to get dropped mid - connection . First flights getting dropped is fine , because clients can do happy - eyeballing . Even if they only use QUIC , not starting a transaction is much better than a transaction inflight getting lost . 
 I 'm with here . As a client , if you send at 1350 and those are all dropped , that reduces to " the path does n't support UDP " . The real risk is if you send at 1200 and then increase that later without first probing . I 'm happy to take this as editorial , but would prefer to confirm that no one wants a substantive change . 
 I agree with : I 'm happy with clarifying that this will look like an MTU issue . 
 One suggestion , but LGTM otherwise . Thanks for updating the adjacent text , this LGTM
Paragraph (version A):
Datagrams containing Initial packets MAY exceed 1200 bytes if the
client believes that the Path Maximum Transmission Unit (PMTU)
supports the size that it chooses.
Paragraph (version A):
A server MUST discard an Initial packet that is carried in a UDP
datagram that is smaller than 1200 bytes.  A server MAY also
immediately close the connection by sending a CONNECTION_CLOSE frame
with an error code of PROTOCOL_VIOLATION; see immediate-close-hs.
Paragraph (version A):
The PMTU is the maximum size of the entire IP packet including the IP
header, UDP header, and UDP payload.  The UDP payload includes the
QUIC packet header, protected payload, and any authentication fields.
The PMTU can depend upon the current path characteristics.
Therefore, the current largest UDP payload an implementation will
send is referred to as the QUIC maximum packet size.
Paragraph (version B):
Enforcement of the max_udp_payload_size transport parameter
(transport-parameter-definitions) might act as an additional limit on
packet size.  Exceeding this limit can be avoided once the value is
known.  However, prior to learning the value of the transport
parameter, endpoints risk datagrams being lost if they send packets
larger than 1200 bytes.
Paragraph (version B):
Datagrams containing Initial packets MAY exceed 1200 bytes if the
client believes that the network path and peer both support the size
that it chooses.
Paragraph (version B):
A server MUST discard an Initial packet that is carried in a UDP
datagram with a payload that is less than 1200 bytes.  A server MAY
also immediately close the connection by sending a CONNECTION_CLOSE
frame with an error code of PROTOCOL_VIOLATION; see immediate-close-
hs.
Paragraph (version B):
The Path Maximum Transmission Unit (PMTU) is the maximum size of the
entire IP packet including the IP header, UDP header, and UDP
payload.  The UDP payload includes the QUIC packet header, protected
payload, and any authentication fields.  The PMTU can depend on path
characteristics, and can therefore change over time.  The largest UDP
payload an endpoint sends at any given time is referred to as the
endpoint's maximum packet size.