Re: [quicwg/base-drafts] Rewrite Packet Size section (#2036)

[martinduke <[e-mail]>]

martinduke commented on this pull request.

Thank you for updating the reference to PLPMTUD.

>  
+The IPv4 Router requirements {{!RFC1812} state that the quoted packet should

RFC 792 requires only 8 bytes of Transport header. While this quite old, it hasn't been formally obsoleted. I've always assumed endpoints needed to handle this case, although I don't have any data as to whether this still really happens in the internet. Hence the original text, which you've removed.

As a related data point, only about 4 years ago we saw ICMP messages where the MTU field was set to zero, which has been outdated for 25+ years. It's a wild world out there.

>  
-The PADDING frame provides a useful option for PMTU probe packets. PADDING
-frames generate acknowledgements, but they need not be delivered reliably. As a
-result, the loss of PADDING frames in probe packets does not require
-delay-inducing retransmission. However, PADDING frames do consume congestion
-window, which may delay the transmission of subsequent application data.
+When implementing the algorithm in Section 5.3 of
+{{!DPLPMTUD}}, the initial value of BASE_PMTU SHOULD be consistent with the
+minimum QUIC packet size (1232 bytes for IPv6 and 1252 bytes for IPv4).

Isn't the BASE_PMTU simply 1280? Is that easier and clearer?

>  
-Section 7.3 of {{!PLPMTUD}} discusses trade-offs between small and large

This text was meant to indicate a point in Section 7.3 that does not apply to QUIC.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2036#pullrequestreview-178599853