Draft: draft-ietf-quic-transport

Commentary: A few minor tweaks based on review of the latest DPLPMTUD draft . If I never have to type DPLPMTUD ever again , I 'll be happy . 
 These comments relate only to the PMTU text in -24 , relative to the current DPLPMTUD text as that now progresses to WGLC . /This can also be used to construct PMTU probes ( see Section 14.3.1 ) . / Is this necessary ? Or can padding frames be used to make ( PL)PMTU probes ? . My confusion here may be linked to not understanding the intent of 14.3.1 /Further validation can also be provided : o An IPv4 endpoint could set the Do n't Fragment ( DF ) bit on a small proportion of packets , so that most invalid ICMP messages arrive when there are no DF packets outstanding , and can therefore be identified as spurious . o An endpoint could store additional information from the IP or UDP headers to use for validation ( for example , the IP ID or UDP checksum)./ I suggest the above text is spurious , since the checks advocated in DPLPMTUD and the QUIC fields provide a way to detect this . While it is possible too toggle the DF field , I do no think the IETF should endorse this , because it can have other side effects and this is not the place to propose that method . /An endpoint MUST NOT increase PMTU based on ICMP messages . / DPLPMTUD already specifies . This has always been the case , so please either delete or cite DPLPMTUD or the two core IP specs . Section 14.3.1 I did n’t understand section 14.3.1 . Maybe that is n’t good since I do understand PMTUD and PLPMTUD . Perhaps this section requires some reworking to explain the goal . 
 Tentatively marking this as editoral ; if something design - y pops up when processing please ping . 
 Let me see if I can break this down a little . cc for his opinion of these . 1 : The first and last comment relates to the section on using coalescing to help the routing of ICMP messages . I had no difficulty reading this section , though I might suggest one tweak : The " further validation " text : DF is currently mandated , but this text pre - dates that requirement . We should drop that clause . And the other clause is a little lame . I 'd be happy dropping all of the quoted text . Citing DPLPMTUDTD is sensible and we should do that . 
 Thanks , LG
Paragraph (version A):
An IPv4 endpoint could set the Don't Fragment (DF) bit on a small
proportion of packets, so that most invalid ICMP messages arrive
when there are no DF packets outstanding, and can therefore be
identified as spurious.
Paragraph (version A):
An endpoint could store additional information from the IP or UDP
headers to use for validation (for example, the IP ID or UDP
checksum).
Paragraph (version A):
An endpoint MUST NOT increase PMTU based on ICMP messages.  Any
reduction in the QUIC maximum packet size MAY be provisional until
QUIC's loss detection algorithm determines that the quoted packet has
actually been lost.
Paragraph (version B):
An endpoint MUST NOT increase PMTU based on ICMP messages; see
Section 3, clause 6 of DPLPMTUD.  Any reduction in the QUIC maximum
packet size in response to ICMP messages MAY be provisional until
QUIC's loss detection algorithm determines that the quoted packet has
actually been lost.
Paragraph (version A):
Endpoints that rely on the destination connection ID for routing QUIC
packets are likely to require that the connection ID be included in
PMTU probe packets to route any resulting ICMP messages (icmp-pmtud)
back to the correct endpoint.  However, only long header packets
(long-header) contain source connection IDs, and long header packets
are not decrypted or acknowledged by the peer once the handshake is
complete.  One way to construct a PMTU probe is to coalesce (see
packet-coalesce) a Handshake packet (packet-handshake) with a short
header packet in a single UDP datagram.  If the UDP datagram reaches
the endpoint, the Handshake packet will be ignored, but the short
header packet will be acknowledged.  If the UDP datagram elicits an
ICMP message, that message will likely contain the source connection
ID within the quoted portion of the UDP datagram.
Paragraph (version B):
Endpoints that rely on the destination connection ID for routing
incoming QUIC packets are likely to require that the connection ID be
included in PMTU probe packets to route any resulting ICMP messages
(icmp-pmtud) back to the correct endpoint.  However, only long header
packets (long-header) contain source connection IDs, and long header
packets are not decrypted or acknowledged by the peer once the
handshake is complete.
Paragraph (version B):
One way to construct a probe for the path MTU is to coalesce (see
packet-coalesce) a Handshake packet (packet-handshake) with a short
header packet in a single UDP datagram.  If the UDP datagram reaches
the endpoint, the Handshake packet will be ignored, but the short
header packet will be acknowledged.  If the UDP datagram causes an
ICMP message to be sent, the first part of the datagram will be
quoted in that message.  If the the source connection ID is within
the quoted portion of the UDP datagram, that could be used for
routing.