Update draft-ietf-quic-transport.md

Addressed Martin T's 01/12 comments.

draft-ietf-quic-transport.md

@@ -1198,23 +1198,28 @@ The fields of a GOAWAY frame are as follows:
 
 # Packetization and Reliability {#packetization}
 
-The maximum packet size for QUIC is the maximum size of the entire UDP payload,
-including the public header, encrypted payload, and any authentication fields.
-All QUIC packets SHOULD be sized to fit within the path's MTU to avoid IP
-fragmentation. To optimize bandwidth efficiency, endpoints MAY use Path MTU
-Discovery ({{!RFC1191}}, {{!RFC1981}}) or Packetization Layer Path MTU
-Discovery ({{!RFC4821}}) for detecting the path's MTU, setting the maximum
-packet size appropriately, and storing the result of previous PMTU
-determinations. In the absence of these mechanisms, the recommended default
-maximum packet size is 1350 bytes for IPv6 and 1370 bytes for IPv4. 
-
-All handshake packets MUST include a PADDING frame if necessary to bring the
-packet to the maximum size the endpoint is enforcing. Furthermore, all IPv4
+The Path Maximum Transmission Unit (PTMU) is the maximum size of the entire IP
+header, UDP header, and UDP payload. The UDP payload includes the QUIC public
+header, encrypted payload, and any authentication fields.
+
+All QUIC packets SHOULD be sized to fit within the estimated PMTU to avoid IP
+fragmentation or packet drops. To optimize bandwidth efficiency, endpoints MAY
+use PMTU Discovery ({{!RFC1191}}, {{!RFC1981}}) or Packetization Layer PMTU
+Discovery ({{!RFC4821}}) for detecting the PMTU, setting the PMTU appropriately,
+and storing the result of previous PMTU determinations.
+
+In the absence of these mechanisms, QUIC endpoints SHOULD use a default PMTU of
+1398 octets. Assuming the minimum IP header size, this results in a UDP payload
+length of 1350 octets for IPv6 and 1370 octets for IPv4.
+
+Both the QUIC client and server MUST send at least one handshake packet of size
+equal to the estimated PMTU, and receive an acknowledgment for that packet. This
+could require a PADDING frame to increase the packet size. PMTU-size, IPv4
 handshake packets SHOULD have the DF bit set.
 
-QUIC endpoints that implement any kind of MTU discovery SHOULD maintain an
+QUIC endpoints that implement any kind of PMTU discovery SHOULD maintain an
 estimate for each combination of local and remote IP addresses (as each pairing
-may have a different maximum MTU in the path).
+could have a different maximum MTU in the path).
 
 A sender bundles one or more frames in a Regular QUIC packet.  A sender MAY
 bundle any set of frames in a packet.  All QUIC packets MUST contain a packet
@@ -1268,26 +1273,26 @@ frames), the receiving peer MAY send an ACK frame after a reasonable number
 Strategies and implications of the frequency of generating acknowledgments are
 discussed in more detail in {{QUIC-RECOVERY}}.
 
-## Special Considerations for Path MTU Discovery 
+## Special Considerations for PMTU Discovery 
 
 Traditional ICMP-based path MTU discovery in IPv4 ({{!RFC1191}} is potentially
-vulnerable to off-path attacks that succesfully guess the IP/port 4-tuple and
+vulnerable to off-path attacks that successfully guess the IP/port 4-tuple and
 reduce the MTU to a bandwidth-inefficient value. TCP connections mitigate this
 risk by using the (at minimum) 8 bytes of transport header echoed in the ICMP
 message to validate the TCP sequence number as valid for the current
 connection. However, as QUIC operates over UDP, in IPv4 the echoed information
-may consist only of the IP and UDP headers, which usually has insufficient
+could consist only of the IP and UDP headers, which usually has insufficient
 entropy to mitigate off-path attacks.
 
 As a result, endpoints that implement PMTUD in IPv4 SHOULD take steps to mitigate
-this risk. For instance, an application may:
+this risk. For instance, an application could:
 
-* Set the IPv4 Don't Fragment (DF) bit on a small number of packets per RTT, so
-that most invalid ICMP messages arrive when there are no DF packets
-outstanding.
+* Set the IPv4 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.
 
-* Store additional information from the IP or UDP headers (for example, the IP
-ID or UDP checksum) to further authenticate incoming Packet Too Big messages.
+* Store additional information from the IP or UDP headers from DF packets (for
+example, the IP ID or UDP checksum) to further authenticate incoming Packet Too
+Big messages.
 
 # Streams: QUIC's Data Structuring Abstraction {#streams}