Draft: draft-ietf-quic-transport

Commentary: This is with some minor additional changes : . the odd text about using Handshake back where it belongs . the language about how to construct a probe less prescriptive . 1200 when referring to the " smallest allowed maximum packet size " so it is clear what that means . 
 I went with " PMTU probe packet " , which is an IP packet . Let me know if that makes sense . 
 OK - There are already " IP packets " and " QUIC packets " - so some other term works fro me . 
 A top - level comment on the term " probing " : In Section : Probing a New Path : A packet containing only probing frames is a " probing packet " , and a packet containing any other frame is a " non - probing packet " . Please be sure that " probe " can not be confused with " probing " in PLPMTUD . 
 In the subsection on “ Packet Size { # packet - size } ” , I think the blocks of text describe two things . There is some general guidance on size , and there are specific instructions for the size of the initial packet . I ’d suggest we do try to separate these two , it would make it much easier for someone to understand the size constraints for forming the initial packet . 
 Regarding the sizing of Initial packets , see . I checked the text for probing and we have " PMTUD probe " in one case and " probing packet " elsewhere . It 's not ideal , but I did n't see any cases that were clearly busted . I do n't have a good idea for alternative labels , but would welcome suggestions . 
 It turns out that coordinating the publication of all the documents is a real challenge . Right now , DPLPMTUD depends on QUIC , which is fine , but it turns out that this is a problem for other things that depend on DPLPMTUD who now transitively depend on QUIC . QUIC could adopt the DPLPMTUD text that is specific to QUIC and loosen this dependency chain . The text changes are relatively modest , see . While this could be editorial , I think that this will require a consensus call . The nature of the changes is such that it should be treated as design . Also , I think that there are substantive changes required . 
 So from an AD perspective , draft - ietf - tsvwg - datagram - plpmtud is currently blocking another document ( ) from being published that has a missref on it . Except for this question of QUIC I am ready to approve draft - ietf - tsvwg - datagram - plpmtud . To me it is also clear that integration of DPLPMTUD done in the QUIC WG will result in less editorial clarity issues that potentially could make an future implementer uncertain . As can already been seen in the PR there a few question that potentially can improve the operation and not unnecessary restrict the operation of DPLPMTUD . From my perspective it looks like the core is a set of minor editorial issues to resolve that will make the DPLPMTUD be clearer and resolve the missref issue and function as well as keeping it in the TSVWG document would . If a little bit more effort is invested after the first step then there is potential for additional improvements .
Paragraph (version A):
The QUIC packet size includes the QUIC header and protected payload,
but not the UDP or IP header.
Paragraph (version B):
The QUIC packet size includes the QUIC header and protected payload,
but not the UDP or IP headers.
Paragraph (version B):
The QUIC maximum packet size is the largest size of QUIC packet that
can be sent across a network path using a single packet.  Any maximum
packet size larger than 1200 bytes can be discovered using Path
Maximum Transmission Unit Discovery (PMTUD; see pmtud) or Datagram
Packetization Layer PMTU Discovery (DPLPMTUD; see dplpmtud).
Paragraph (version B):
Enforcement of the max_udp_payload_size transport parameter
(transport-parameter-definitions) might act as an additional limit on
the maximum packet size.  A sender can avoid exceeding this limit,
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 the smallest allowed maximum packet size of 1200
bytes.
Paragraph (version B):
A client MUST expand the payload of all UDP datagrams carrying
Initial packets to at least the smallest allowed maximum packet size
(1200 bytes) by adding PADDING frames to the Initial packet or by
coalescing the Initial packet; see packet-coalesce.  Sending a UDP
datagram of this size ensures that the network path from the client
to the server supports a reasonable Path Maximum Transmission Unit
(PMTU).  This also helps reduce the amplitude of amplification
attacks caused by server responses toward an unverified client
address; see address-validation.
Paragraph (version B):
A server MUST discard an Initial packet that is carried in a UDP
datagram with a payload that is less than the smallest allowed
maximum packet size of 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):
QUIC depends on a PMTU of at least 1280 bytes.  This is the IPv6
minimum size RFC8200 and is also supported by most modern IPv4
networks.  All QUIC packets (except for PMTU probe packets) SHOULD be
sized to fit within the maximum packet size to avoid the packet being
fragmented or dropped RFC8085.
Paragraph (version A):
An endpoint SHOULD use Datagram Packetization Layer PMTU Discovery
(DPLPMTUD) or implement Path MTU Discovery (PMTUD) RFC1191 RFC8201 to
determine whether the path to a destination will support a desired
message size without fragmentation.
Paragraph (version A):
In the absence of these mechanisms, QUIC endpoints SHOULD NOT send IP
packets larger than 1280 bytes.  Assuming the minimum IP header size,
this results in a QUIC maximum packet size of 1232 bytes for IPv6 and
1252 bytes for IPv4.  A QUIC implementation MAY be more conservative
in computing the QUIC maximum packet size to allow for unknown tunnel
overheads or IP header options/extensions.
Paragraph (version A):
An endpoint MUST ignore an ICMP message that claims the PMTU has
decreased below 1280 bytes.
Paragraph (version B):
An endpoint SHOULD use DPLPMTUD (dplpmtud) or PMTUD (pmtud) to
determine whether the path to a destination will support a desired
maximum packet size without fragmentation.  In the absence of these
mechanisms, QUIC endpoints SHOULD NOT send IP packets larger than the
smallest allowed maximum packet size.
Paragraph (version B):
If a QUIC endpoint determines that the PMTU between any pair of local
and remote IP addresses has fallen below the smallest allowed maximum
packet size of 1200 bytes, it MUST immediately cease sending QUIC
packets, except for those in PMTU probes or those containing
CONNECTION_CLOSE frames, on the affected path.  An endpoint MAY
terminate the connection if an alternative path cannot be found.
Paragraph (version B):
A QUIC implementation MAY be more conservative in computing the
maximum packet size to allow for unknown tunnel overheads or IP
header options/extensions.
Paragraph (version B):
Path Maximum Transmission Unit Discovery (PMTUD; RFC1191, RFC8201)
relies on reception of ICMP messages (e.g., IPv6 Packet Too Big
messages) that indicate when a packet is dropped because it is larger
than the local router MTU.  DPLPMTUD can also optionally use these
messages.  This use of ICMP messages is potentially vulnerable to
off-path attacks that successfully guess the addresses used on the
path and reduce the PMTU to a bandwidth-inefficient value.
Paragraph (version B):
An endpoint MUST ignore an ICMP message that claims the PMTU has
decreased below the minimum QUIC packet size.
Paragraph (version A):
PING and PADDING frames can be used to generate PMTU probe packets.
These frames might not be retransmitted if a probe packet containing
them is lost.  However, these frames do consume congestion window,
which could delay the transmission of subsequent application data.
Paragraph (version A):
A PING frame can be included in a PMTU probe to ensure that a valid
probe is acknowledged.
Paragraph (version A):
The considerations for processing ICMP messages in the previous
section also apply if these messages are used by DPLPMTUD.
Paragraph (version A):
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 source connection ID is within the
quoted portion of the UDP datagram, that could be used for routing.
Paragraph (version B):
Datagram Packetization Layer PMTU Discovery (DPLPMTUD; DPLPMTUD)
relies on tracking loss or acknowledgment of QUIC packets that are
carried in PMTU probes.  PMTU probes for DPLPMTUD that use the
PADDING frame implement "Probing using padding data", as defined in
Section 4.1 of DPLPMTUD.
Paragraph (version B):
Endpoints SHOULD set the initial value of BASE_PMTU (see Section 5.1
of DPLPMTUD) to be consistent with the minimum QUIC packet size.  The
MIN_PLPMTU is the same as the BASE_PMTU.
Paragraph (version B):
QUIC endpoints implementing DPLPMTUD maintain a maximum packet size
(DPLPMTUD MPS) for each combination of local and remote IP addresses.
Paragraph (version B):
QUIC provides an acknowledged PL, therefore a sender does not
implement the DPLPMTUD CONFIRMATION_TIMER while in the
SEARCH_COMPLETE state; see Section 5.2 of DPLPMTUD.
Paragraph (version B):
An endpoint using DPLPMTUD requires the validation of any received
ICMP Packet Too Big (PTB) message before using the PTB information,
as defined in Section 4.6 of DPLPMTUD.  In addition to UDP port
validation, QUIC validates an ICMP message by using other PL
information (e.g., validation of connection IDs in the quoted packet
of any received ICMP message).
Paragraph (version B):
The considerations for processing ICMP messages described in pmtud
also apply if these messages are used by DPLPMTUD.
Paragraph (version B):
PMTU probes are ack-eliciting packets.
Paragraph (version B):
Endpoints could limit the content of PMTU probes to PING and PADDING
frames as packets that are larger than the current maximum packet
size are more likely to be dropped by the network.  Loss of a QUIC
packet that is carried in a PMTU probe is therefore not a reliable
indication of congestion and SHOULD NOT trigger a congestion control
reaction; see Section 3, Bullet 7 of DPLPMTUD.  However, PMTU probes
consume congestion window, which could delay subsequent transmission
by an application.
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 probes to route any resulting ICMP messages (pmtud)
back to the correct endpoint.  However, only long header packets
(long-header) contain the Source Connection ID field, 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 PMTU probe is to coalesce (see packet-
coalesce) a packet with a long header, such as a Handshake or 0-RTT
packet (long-header), with a short header packet in a single UDP
datagram.  If the resulting PMTU probe reaches the endpoint, the
packet with the long header will be ignored, but the short header
packet will be acknowledged.  If the PMTU probe causes an ICMP
message to be sent, the first part of the probe will be quoted in
that message.  If the Source Connection ID field is within the quoted
portion of the probe, that could be used for routing or validation of
the ICMP message.
Paragraph (version B):
The purpose of using a packet with a long header is only to ensure
that the quoted packet contained in the ICMP message contains a
Source Connection ID field.  This packet does not need to be a
valid packet and it can be sent even if there is no current use
for packets of that type.
Paragraph (version A):
Once a connection is established QUIC endpoints might accept some
unauthenticated ICMP packets (see icmp-pmtud), but the use of these
packets is extremely limited.  The only other type of packet that an
endpoint might accept is a stateless reset (stateless-reset) which
relies on the token being kept secret until it is used.
Paragraph (version B):
Once a connection is established QUIC endpoints might accept some
unauthenticated ICMP packets (see pmtud), but the use of these
packets is extremely limited.  The only other type of packet that an
endpoint might accept is a stateless reset (stateless-reset) which
relies on the token being kept secret until it is used.