From a13df5dda0e30cee0f4556c17f3c587480c6b5dc Mon Sep 17 00:00:00 2001 From: martinduke Date: Mon, 9 Oct 2017 22:18:54 -0700 Subject: [PATCH 1/3] Add some suggestions for RFC 4821 probe packets. --- draft-ietf-quic-transport.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 3e6a99edcf..7838e57f3b 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2403,6 +2403,15 @@ that it sends. Strategies and implications of the frequency of generating acknowledgments are discussed in more detail in {{QUIC-RECOVERY}}. +# Special Considerations for Packetization Layer PMTU Discovery + +The PADDING frame provides a useful option for PMTU probe packets that does not +exist in other transports. QUIC Packets with no frames other than PADDING must be +acknowledged, but need not be retransmitted if lost. PADDING probe packets, if +lost, also do not delay delivery of application data. Their only impact on +application data is the extent that they consume the congestion window and +connection flow control credits. + ## Special Considerations for PMTU Discovery Traditional ICMP-based path MTU discovery in IPv4 {{!RFC1191}} is potentially From 54c56d6dd4466443116a0bed94b0dd8dfd0952c8 Mon Sep 17 00:00:00 2001 From: martinduke Date: Tue, 10 Oct 2017 11:09:21 -0700 Subject: [PATCH 2/3] Update draft-ietf-quic-transport.md Addressed @martinthomson's editorial comments. --- draft-ietf-quic-transport.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 7838e57f3b..07b6fdc8e3 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2405,12 +2405,12 @@ discussed in more detail in {{QUIC-RECOVERY}}. # Special Considerations for Packetization Layer PMTU Discovery -The PADDING frame provides a useful option for PMTU probe packets that does not -exist in other transports. QUIC Packets with no frames other than PADDING must be -acknowledged, but need not be retransmitted if lost. PADDING probe packets, if -lost, also do not delay delivery of application data. Their only impact on -application data is the extent that they consume the congestion window and -connection flow control credits. +The PADDING frame provides a useful option for PMTU probe packets that does +not exist in other transports. PADDING frames generate acknowledgements, but +their content need not be delivered reliably. PADDING frames may delay the +delivery of application data, as they consume the congestion window. However, +by definition their likely loss in a probe packet does not require delay- +inducing retransmission of application data. ## Special Considerations for PMTU Discovery From 766b2da03d35a34ccbc3fc8c0ceb98f48982913c Mon Sep 17 00:00:00 2001 From: martinduke Date: Wed, 8 Nov 2017 15:52:30 -0800 Subject: [PATCH 3/3] Update draft-ietf-quic-transport.md Added a little language based on @gloinul's comments in #614. --- draft-ietf-quic-transport.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 07b6fdc8e3..532836c4c6 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2412,6 +2412,16 @@ delivery of application data, as they consume the congestion window. However, by definition their likely loss in a probe packet does not require delay- inducing retransmission of application data. +When implementing the algorithm in Section 7.2 of {{!RFC4821}}, the initial +value of search_low SHOULD be consistent with the IPv6 minimum packet size. +Paths that do not support this size cannot deliver Client Initial packets, +and therefore are not QUIC-compliant. + +Section 7.3 of {{!RFC4821}} discusses tradeoffs between small and large +increases in the size of probe packets. As QUIC probe packets need not +contain application data, aggressive increases in probe size carry fewer +consequences. + ## Special Considerations for PMTU Discovery Traditional ICMP-based path MTU discovery in IPv4 {{!RFC1191}} is potentially