Draft: draft-ietf-quic-transport

Commentary: Addresses . points out in that we use in the transport draft and in the recovery draft . In reading carefully , I realized that in the transport draft was actually historical , and is the more appropriate term . This is an entirely editorial PR , and it 's largely simple changes , despite the fact that it looks a bit big . It is a bit subtle though . Sorry about that . 
 This issue will list a number of minor editorial things that should be checked and likely addressed with some editorial fixes : 5.3 : " These delays are computed using the ACK Delay field of the ACK frame as described in Section 19.3 of [ QUIC - TRANSPORT ] . " This text implies that the computation of the delay is described in Section 19.3 of QUIC - TRANSPORT . However , I do n't think it is described the calculation , only the definition of the field . Please reformulate to imply only field definition not calculation . 5.3 : " On the first RTT sample for the network path , that sample is used as rttsample . This ensures that the first measurement erases the history of any persisted or default values . " I think this intended to cover cases where path changes are detected . But it is not well expressed . Does this need a reformulation and a reference into QUIC - TRANSPORT where it states when such a reset should occur ? 6.1 : " Either its packet number is kPacketThreshold smaller than an acknowledged packet " Nitpicking , assuming no PN gaps in transmission . Does that need a note ? 6.2.4 : " An endpoint MAY send up to two full - sized datagrams containing ack - eliciting packets , to avoid an expensive consecutive PTO expiration due to a single lost datagram or transmit data from multiple packet number spaces . " This last part , I assume intended to generate additional datagrams to prevent single loss to impact . However , due to coalescing this is unclear in this context . 7 : " Endpoints can unilaterally choose a different algorithm to use , such as  ( [ RFC8312 ] ) . " I think this sentence should be explicit that in needs to be sender - based algorithms . I think we need to have the requirement on performing congestion control on the sender unless there has been explicit agreement with the receiver that they will do it . 7.2 : " Endpoints SHOULD use an initial congestion window of 10 times the maximum datagram size ( maxdatagramsize ) , limited to the larger of bytes or twice the maximum datagram size . " " maximum datagram size " is not used in Transport there need to be alignment here of what name to use . Transport has Maximum Packet Size , which appears to match the definition in the appendix of maxdatagram_size . 
 Thanks for your careful review , -- these are good finds ! I 've addressed your comments below and in . I 'll address point 6 in a separate PR . 19.3 has the following text , which does tell how to compute acknowledgement delay from the ACK Delay field : I 've replaced " computed " with " decoded " in the recovery document to make it clearer . applies to packets , not to datagrams . We 've explicitly stated that a sender could send 2 datagrams to avoid any effects of coalescing . I think the text is pretty clear on this : " An endpoint MAY send up to two full - sized datagrams containing ack - eliciting packets " . ' ve " sender - side " to make the controller more explicit . To your point about making this a sender requirement , that is covered in the transport doc ( end of ): 
 Based on and , labeling this as " editorial " 
 I think these issues are resolved once the two PRs are completely ready . 
 Except for the one erronous exchange of packet this looks good .
Paragraph (version A):
packet-size specifies rules for managing the size of packets.
Paragraph (version B):
datagram-size specifies rules for managing the size of
datagrams carrying QUIC packets.
Paragraph (version A):
The QUIC packet size includes the QUIC header and protected payload,
but not the UDP or IP headers.
Paragraph (version A):
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 A):
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 UDP datagram can include one or more QUIC packets.  The datagram
size refers to the total UDP payload size of a single UDP datagram
carrying QUIC packets.  The datagram size includes one or more QUIC
packet headers and protected payloads, but not the UDP or IP headers.
Paragraph (version B):
Any maximum datagram 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 datagram 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
datagrams larger than the smallest allowed maximum datagram size of
1200 bytes.
Paragraph (version A):
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 client MUST expand the payload of all UDP datagrams carrying
Initial packets to at least the smallest allowed maximum datagram
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 A):
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 B):
A server MUST discard an Initial packet that is carried in a UDP
datagram with a payload that is smaller than the smallest allowed
maximum datagram 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):
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 A):
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 A):
Each pair of local and remote addresses could have a different PMTU.
QUIC implementations that implement any kind of PMTU discovery
therefore SHOULD maintain a maximum packet size for each combination
of local and remote IP addresses.
Paragraph (version A):
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 A):
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 A):
An endpoint MUST ignore an ICMP message that claims the PMTU has
decreased below the minimum QUIC packet size.
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 one or more QUIC packet headers
and protected payloads.  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 datagram size.
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 datagram size without fragmentation.  In the absence of these
mechanisms, QUIC endpoints SHOULD NOT send datagrams larger than the
smallest allowed maximum datagram size.
Paragraph (version B):
Both DPLPMTUD and PMTUD send datagrams that are larger than the
current maximum datagram size, referred to as PMTU probes.  All QUIC
packets that are not sent in a PMTU probe SHOULD be sized to fit
within the maximum datagram size to avoid the datagram being
fragmented or dropped (RFC8085).
Paragraph (version B):
Each pair of local and remote addresses could have a different PMTU.
QUIC implementations that implement any kind of PMTU discovery
therefore SHOULD maintain a maximum datagram size for each
combination of local and remote IP addresses.
Paragraph (version B):
A QUIC implementation MAY be more conservative in computing the
maximum datagram size to allow for unknown tunnel overheads or IP
header options/extensions.
Paragraph (version B):
An endpoint MUST ignore an ICMP message that claims the PMTU has
decreased below QUIC's smallest allowed maximum datagram size.
Paragraph (version B):
An endpoint MUST NOT increase PMTU based on ICMP messages; see
Section 3, clause 6 of DPLPMTUD.  Any reduction in QUIC's maximum
datagram 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 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 A):
QUIC endpoints implementing DPLPMTUD maintain a maximum packet size
(DPLPMTUD MPS) for each combination of local and remote IP addresses.
Paragraph (version A):
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):
Endpoints SHOULD set the initial value of BASE_PLPMTU (Section 5.1 of
DPLPMTUD) to be consistent with QUIC's smallest allowed maximum
datagram size.  The MIN_PLPMTU is the same as the BASE_PLPMTU.
Paragraph (version B):
QUIC endpoints implementing DPLPMTUD maintain a DPLPMTUD Maximum
Packet Size (MPS, Section 4.4 of DPLPMTUD) for each combination of
local and remote IP addresses.  This corresponds to the maximum
datagram size.
Paragraph (version B):
From the perspective of DPLPMTUD, QUIC is an acknowledged
Packetization Layer (PL).  A QUIC sender can therefore enter the
DPLPMTUD BASE state (Section 5.2 of DPLPMTUD) when the QUIC
connection handshake has been completed.
Paragraph (version B):
QUIC is an acknowledged PL, therefore a QUIC sender does not
implement a DPLPMTUD CONFIRMATION_TIMER while in the SEARCH_COMPLETE
state; see Section 5.2 of DPLPMTUD.
Paragraph (version A):
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 could limit the content of PMTU probes to PING and PADDING
frames, since packets that are larger than the current maximum
datagram 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 A):
This limit does act as an additional constraint on datagram size
in the same way as the path MTU, but it is a property of the
endpoint and not the path; see packet-size.  It is expected that
this is the space an endpoint dedicates to holding incoming
packets.
Paragraph (version B):
This limit does act as an additional constraint on datagram size
in the same way as the path MTU, but it is a property of the
endpoint and not the path; see datagram-size.  It is expected that
this is the space an endpoint dedicates to holding incoming
packets.