Subject: [quicwg/base-drafts] DPLPMTU merge tweaks (#3702)

From: Martin Thomson <[email-masked]>
Date: Tue, 26 May 2020 17:35:08 -0700

This is #3693 with some minor additional changes:

1. Reflow.
2. Move the odd text about using Handshake back where it belongs.
3. Make the language about how to construct a probe less prescriptive.
4. Mention 1200 when referring to the &quot;smallest allowed maximum packet size&quot; so it is clear what that means.

Closes #3693.
Closes #3695.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/3702

-- Commit Summary --

  * Update draft-ietf-quic-transport.md
  * Update draft-ietf-quic-transport.md
  * Update draft-ietf-quic-transport.md
  * Update draft-ietf-quic-transport.md
  * Update draft-ietf-quic-transport.md
  * Update draft-ietf-quic-transport.md
  * Update draft-ietf-quic-transport.md
  * Update draft-ietf-quic-transport.md
  * Update draft-ietf-quic-transport.md
  * Update draft-ietf-quic-transport.md
  * Update draft-ietf-quic-transport.md
  * Update draft-ietf-quic-transport.md
  * Update draft-ietf-quic-transport.md
  * Update draft-ietf-quic-transport.md
  * Update draft-ietf-quic-transport.md
  * Reflow
  * Move section back where it belongs
  * PING AND PADDING are not it
  * Add a number for clarity

-- File Changes --

    M draft-ietf-quic-transport.md (150)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/3702.patch
https://github.com/quicwg/base-drafts/pull/3702.diff

-- 
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/3702

---

From: Martin Thomson <[email-masked]>
Date: Wed, 27 May 2020 00:19:54 -0700

@martinthomson pushed 1 commit.

cbfb4d1d7e5edaca5829327d82c3f983c5c32cd8  Use long header packets generically and explain why

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3702/files/1a9c864eef75fa0e2d9dd78db7c714dae9b84625..cbfb4d1d7e5edaca5829327d82c3f983c5c32cd8

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 27 May 2020 02:24:15 -0700

@gorryfair commented on this pull request.

This reflow of the text seems clear to me, and seems nearly ready. I have carefully checked the text and I think this covers all issues and responds to all discussion, thanks. There are a small number of NiTs and one or two small questions remain.

-The considerations for processing ICMP messages in the previous section also
+From the perspective of DPLPMTUD, QUIC transport is an acknowledged
+packetization layer (PL). A sender can therefore enter the DPLPMTUD BASE state
+when the QUIC connection handshake has been completed and the endpoint has
+established a 1-RTT key.

I think we agreed to remove the 1-RTT clause (as not needed)?

> -
-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.
+packets are likely to require that the connection ID be included in
+PMTUD/DPLPMTUD probe packets to route any resulting ICMP messages
+({{icmp-pmtud}}) back to the correct endpoint.  However, only long header
+packets ({{long-header}}) contain source connection IDs, and long header packets
+are not decrypted or acknowledged by the peer once the handshake is complete.
+
+One way to construct a PMTU probe is to coalesce (see {{packet-coalesce}}) a

Re-reading this: Is this only for PMTUD? 

The text seems to describe a probe packet that is ack-eliciting, which may mean it can be used with PLPMTUD?
Should we say PMTUD/DPLPMTUD

-The considerations for processing ICMP messages in the previous section also
+From the perspective of DPLPMTUD, QUIC transport is an acknowledged
+packetization layer (PL). A sender can therefore enter the DPLPMTUD BASE state
+when the QUIC connection handshake has been completed and the endpoint has
+established a 1-RTT key.
+
+
+### Sending QUIC DPLPMTUD Probe Packets
+
+DPLPMTU probe packets are ack-eliciting packets.  Probe packets that use the
+PADDING frame therefore implement "Probing using padding data", as defined in
+Section 4.1 of {{!DPLPMTUD}}.  Endpoints could limit the content of probe
+packets to PING and PADDING frames as packets that are larger than the current

Please check: This may leave data in probe packets slightly under-described, and I think more may need to be said:

The transmission of data in probe packets in discussed in
section 4.1 of {{!DPLPMTUD}}. Probe packets that use a PADDING frame or that coalesce packets with no data implement DPLPMTUD with "Probing using padding data".

> @@ -3797,19 +3797,24 @@ later time in the connection.
 The QUIC packet size includes the QUIC header and protected payload, but not the
 UDP or IP header.
 
+QUIC depends upon a minimum packet size of at least 1280 bytes.  This is the

The protocol layer relating to "packet size" needs clarification - is it an IP packet or an IP payload, or QUIC packet?

>  A client MUST expand the payload of all UDP datagrams carrying Initial packets
 to at least 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 Maximum Transmission Unit (MTU).  Padding datagrams also
-helps reduce the amplitude of amplification attacks caused by server responses
-toward an unverified client address; see {{address-validation}}.
+supports a reasonable Path Maximum Transmission Unit (PMTU).  Padding datagrams

/reasonable/minimum size required by QUIC/

>  A client MUST expand the payload of all UDP datagrams carrying Initial packets
 to at least 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 Maximum Transmission Unit (MTU).  Padding datagrams also
-helps reduce the amplitude of amplification attacks caused by server responses
-toward an unverified client address; see {{address-validation}}.
+supports a reasonable Path Maximum Transmission Unit (PMTU).  Padding datagrams

... If coalescing also has this property, should we say:
/Passing datagrams/Using the minimum packet size/

> -used for routing.
+packets are likely to require that the connection ID be included in
+PMTUD/DPLPMTUD probe packets to route any resulting ICMP messages
+({{icmp-pmtud}}) back to the correct endpoint.  However, only long header
+packets ({{long-header}}) contain source connection IDs, and long header packets
+are not decrypted or acknowledged by the peer once the handshake is complete.
+
+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
+UDP datagram reaches the endpoint, the packet with the long header 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.
+

used for routing ... add: /and for validation of an ICMP message./

> +({{icmp-pmtud}}) back to the correct endpoint.  However, only long header
+packets ({{long-header}}) contain source connection IDs, and long header packets
+are not decrypted or acknowledged by the peer once the handshake is complete.
+
+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
+UDP datagram reaches the endpoint, the packet with the long header 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.
+
+Note:
+: 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

/SCID/ may already be defined if you prefer.

> +packets ({{long-header}}) contain source connection IDs, and long header packets
+are not decrypted or acknowledged by the peer once the handshake is complete.
+
+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
+UDP datagram reaches the endpoint, the packet with the long header 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.
+
+Note:
+: 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 that can be use for routing.  This packet does not need to be a valid

...only for routing? Does this help with validation (the editor will know best).

> -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.
+packets are likely to require that the connection ID be included in
+PMTUD/DPLPMTUD probe packets to route any resulting ICMP messages
+({{icmp-pmtud}}) back to the correct endpoint.  However, only long header
+packets ({{long-header}}) contain source connection IDs, and long header packets
+are not decrypted or acknowledged by the peer once the handshake is complete.
+
+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
+UDP datagram reaches the endpoint, the packet with the long header 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

I think these may already be defined, you could use them if toy prefer: /CID/ or /SCID/.

> +DPLPMTU probe packets consume congestion window, which could delay subsequent
+transmission by an application.
+
+
+### Validating the QUIC Path with DPLPMTUD
+
+QUIC provides an acknowledged PL, therefore a sender does not implement the
+DPLPMTUD CONFIRMATION_TIMER while in the SEARCH_COMPLETE state.
+
+
+### Handling of ICMP Messages by DPLPMTUD
+
+An endpoint using DPLPMTUD requires the validation of any received 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 identifiers (CIDs) in the

I think /CID/ is already defined at this point in the ID.

-- 
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/3702#pullrequestreview-418950412

---

From: Martin Thomson <[email-masked]>
Date: Wed, 27 May 2020 16:30:23 -0700

@martinthomson pushed 3 commits.

0d82ddcf5def2a4c3cc72d31384d302a1e7cd4dc  Update draft-ietf-quic-transport.md
4692d921098e16403fb2406aca767a5d1475520b  Update draft-ietf-quic-transport.md
0d20f5448aa08f89ae439e49bbeb9653aa62d5b3  Merge branch 'patch-2' of https://github.com/gorryfair/base-drafts into dplpmtud-merge

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3702/files/cbfb4d1d7e5edaca5829327d82c3f983c5c32cd8..0d20f5448aa08f89ae439e49bbeb9653aa62d5b3

---

From: Martin Thomson <[email-masked]>
Date: Wed, 27 May 2020 16:45:11 -0700

fef600022a6c6e770ac905b529c6f394da7c11ae  Reflow

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3702/files/0d20f5448aa08f89ae439e49bbeb9653aa62d5b3..fef600022a6c6e770ac905b529c6f394da7c11ae

---

From: Martin Thomson <[email-masked]>
Date: Wed, 27 May 2020 18:14:03 -0700

@martinthomson pushed 4 commits.

e01a0418dcfad8d7e325693527eb16239f976639  IP packet size is 1280
a31a0460749712ff89d41a05a7320470fcf3bd21  Remove duplicate text
a9b7969b608081162ae67f7f2bf89f5cb5532b4d  Remove has 1-RTT key clause as redundant
d28c636b08e147fa7d056f6ebc2e65b85b88243e  Editorial comments based on Gorry's feedback

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3702/files/fef600022a6c6e770ac905b529c6f394da7c11ae..d28c636b08e147fa7d056f6ebc2e65b85b88243e

---

From: Martin Thomson <[email-masked]>
Date: Wed, 27 May 2020 18:14:29 -0700

@martinthomson commented on this pull request.

Thanks for the review Gorry.  You caught a few mistakes - one of them being quite old.

Good point.  That's been sitting there for ages and you are the first to notice.

Yep.  Missed that in my pass.  Corrected.

The coalescing part sort of reveals a flaw in the construction though.  It shows that the probe really uses datagrams.  At this level, I think that assuming the hack (coalescing with junk Handshake) is not involved, is OK.  Happy to take suggestions though, because this is definitely awkward.

I don't think we use is, so thanks for drawing attention to it.  We use "connection ID" and so I have fixed this.

Yeah, this should be either.

Good point.  And it is either.  (Though using other junk in the packet might be better for validation, if the quoted part is indeed long enough.  One real concern with this hack is that the router might not quote enough of the packet include the the whole Source Connection ID field, especially if the Destination Connection ID - which you can't truncate either - has to be longer.)

We've taken to writing these out in full.

-- 
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/3702#pullrequestreview-419710667

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 27 May 2020 18:19:25 -0700

@janaiyengar requested changes on this pull request.

A high order point. This could use a clean up in terms of noun consistency:
- PMTU, DPLPMPTU
- PMTUD/DPLPMTUD/PMTU/DPLPMTU probes / probe packets. I would simply use "probes" and define this away.

My suggestion would be to add a `Terminology` subsection at the top of this section, so that we can simply define away the ambiguities.

> @@ -3795,37 +3795,48 @@ later time in the connection.
 # Packet Size {#packet-size}
 
 The QUIC packet size includes the QUIC header and protected payload, but not the
-UDP or IP header.
+UDP or IP headers.
+
+QUIC depends upon a minimum packet size of at least 1280 bytes.  This is the
+IPv6 minimum size {{?RFC8200}} and is also supported by most modern IPv4
+networks.  Assuming the minimum IP header size, this results in a QUIC maximum
+packet size of 1232 bytes for IPv6 and 1252 bytes for IPv4.
+
+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 is discovered using PMTUD/DPLPMTUD.

```suggestion
1200 bytes can be discovered using PMTUD/DPLPMTUD.
```

> @@ -3900,42 +3917,82 @@ determines that the quoted packet has actually been lost.
 
 ## Datagram Packetization Layer PMTU Discovery
 
-Section 6.3 of {{!DPLPMTUD}} provides considerations for implementing Datagram
-Packetization Layer PMTUD (DPLPMTUD) with QUIC.
+When implementing the algorithm in Section 5 of {{!DPLPMTUD}}, the initial value
+of BASE_PMTU SHOULD be consistent with the minimum QUIC packet size. The
+MIN_PLPMTU is the same as the BASE_PMTU.
+
+QUIC endpoints implementing DPLPMTUD maintain a maximum packet size (DPLPMTUD
+MPS) for each combination of local and remote IP addresses.
+
+If a QUIC endpoint determines that the PLPMTU between any pair of local and
+remote IP addresses has fallen below the size needed to support the minimum QUIC
+packet size (BASE_PLPMTU), it MUST immediately cease sending QUIC packets,
+except for DPLPMTUD probe packets, on the affected path. An endpoint MAY

This clause does not make sense to me. What does a DPLPMTUD probe packet look like if it's not a QUIC packet? I think this clause should be removed.

+QUIC endpoints implementing DPLPMTUD maintain a maximum packet size (DPLPMTUD
+MPS) for each combination of local and remote IP addresses.
+
+If a QUIC endpoint determines that the PLPMTU between any pair of local and
+remote IP addresses has fallen below the size needed to support the minimum QUIC
+packet size (BASE_PLPMTU), it MUST immediately cease sending QUIC packets,
+except for DPLPMTUD probe packets, on the affected path. An endpoint MAY
+terminate the connection if an alternative path cannot be found.
+
+
+### DPLPMTUD and Initial Connectivity
+
+From the perspective of DPLPMTUD, QUIC transport is an acknowledged
+packetization layer (PL). A sender can therefore enter the DPLPMTUD BASE state
+when the QUIC connection handshake has been completed and the endpoint has

This should use "handshake confirmed". That said, is there a reason to disallow this during the handshake?

> +packet size (BASE_PLPMTU), it MUST immediately cease sending QUIC packets,
+except for DPLPMTUD probe packets, on the affected path. An endpoint MAY
+terminate the connection if an alternative path cannot be found.
+
+
+### DPLPMTUD and Initial Connectivity
+
+From the perspective of DPLPMTUD, QUIC transport is an acknowledged
+packetization layer (PL). A sender can therefore enter the DPLPMTUD BASE state
+when the QUIC connection handshake has been completed and the endpoint has
+established a 1-RTT key.
+
+
+### Sending QUIC DPLPMTUD Probe Packets
+
+DPLPMTU probe packets are ack-eliciting packets.  Probe packets that use the

This sounds like we are using a term without defining it. Perhaps "DPLPMTU probe packets require acknowledgements (Section 3 of {{!DPLPMTUD}}), and are therefore ack-eliciting packets"?

> +except for DPLPMTUD probe packets, on the affected path. An endpoint MAY
+terminate the connection if an alternative path cannot be found.
+
+
+### DPLPMTUD and Initial Connectivity
+
+From the perspective of DPLPMTUD, QUIC transport is an acknowledged
+packetization layer (PL). A sender can therefore enter the DPLPMTUD BASE state
+when the QUIC connection handshake has been completed and the endpoint has
+established a 1-RTT key.
+
+
+### Sending QUIC DPLPMTUD Probe Packets
+
+DPLPMTU probe packets are ack-eliciting packets.  Probe packets that use the
+PADDING frame therefore implement "Probing using padding data", as defined in

```suggestion
PADDING frame implement "Probing using padding data", as defined in
```

-A PING frame can be included in a PMTU probe to ensure that a valid probe is
-acknowledged.
+QUIC provides an acknowledged PL, therefore a sender does not implement the
+DPLPMTUD CONFIRMATION_TIMER while in the SEARCH_COMPLETE state.

```suggestion
DPLPMTUD CONFIRMATION_TIMER while in the SEARCH_COMPLETE state; see Section
5.2 of {{!DPLPMTUD}}.
```

Yes, this was starting to leak badly. I think there's some cleaning up that needs to be done in terms of bringing consistency overall, see meta comment above.

-- 
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/3702#pullrequestreview-419695894

---

From: Martin Thomson <[email-masked]>
Date: Wed, 27 May 2020 18:31:33 -0700

26e301f5a1e0dc190816791220f5fe7a5d66cd3d  Remove probing clause

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3702/files/d28c636b08e147fa7d056f6ebc2e65b85b88243e..26e301f5a1e0dc190816791220f5fe7a5d66cd3d

---

From: Martin Thomson <[email-masked]>
Date: Wed, 27 May 2020 18:32:40 -0700

ad691c836127271e114713893c5b35e20e6f3ad4  Small edits

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3702/files/26e301f5a1e0dc190816791220f5fe7a5d66cd3d..ad691c836127271e114713893c5b35e20e6f3ad4

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 27 May 2020 19:44:18 -0700

These look goof to me.

-- 
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/3702#pullrequestreview-419740048

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 27 May 2020 19:58:04 -0700

Works for me.

-- 
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/3702#discussion_r431554510

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 27 May 2020 20:01:02 -0700

I am fine to remove: DPLPMTUD will anyway send some "probes" after it thinks a blackhole is detected, to confirm if the black hole exists. Once confirmed I understand QUIC will cease sending.

-- 
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/3702#discussion_r431555184

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 27 May 2020 20:06:44 -0700

:-). (Knowing that needs a measurement survey) However, the implications are you wouldn't be able to rely on ICMP to help you. Well that's no new news there are many reasons why you may not see a PTB message, that's why DPLPMTUD was made.

-- 
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/3702#discussion_r431556514

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 27 May 2020 20:06:55 -0700

:-)

-- 
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/3702#discussion_r431556550

---

From: msvoelker <[email-masked]>
Date: Thu, 28 May 2020 08:45:56 -0700

@msvoelker commented on this pull request.

+From the perspective of DPLPMTUD, QUIC transport is an acknowledged
+packetization layer (PL). A sender can therefore enter the DPLPMTUD BASE state
+when the QUIC connection handshake has been completed.
+
+
+### Sending QUIC DPLPMTUD Probe Packets
+
+DPLPMTU probe packets are ack-eliciting packets.  Probe packets that use the
+PADDING frame implement "Probing using padding data", as defined in
+Section 4.1 of {{!DPLPMTUD}}.  Endpoints could limit the content of probe
+packets 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.
+
+DPLPMTU probe packets consume congestion window, which could delay subsequent
+transmission by an application.

I think here is more to consider. QUIC's loss detection will trigger on a lost probe packet. Even tough this does not lead to a retransmission, since PING and PAD frames won't be retransmitted, one could misinterpret the loss as a congestion signal. It might worth to note that a lost probe packet should not be treated as a congestion signal by the congestion control.

-- 
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/3702#pullrequestreview-420247600

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 28 May 2020 08:51:13 -0700

Section 3, bullet 7 of DPLPMTUD clarifies this as: "Loss of a probe packet SHOULD NOT be treated as an indication of congestion and SHOULD NOT trigger a congestion control reaction". Maybe this could be added as clarification?

-- 
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/3702#discussion_r431942184

---

From: Martin Thomson <[email-masked]>
Date: Thu, 28 May 2020 16:55:30 -0700

Maybe one of you can make a suggestion for what this can say (or file an issue for follow-up).

-- 
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/3702#discussion_r432185781

---

From: msvoelker <[email-masked]>
Date: Fri, 29 May 2020 05:56:03 -0700

Does this makes sense? (I merged both paragraphs in the section)

... Endpoints could limit the content of probe packets 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. These frames might not be retransmitted if a probe packet containing them is lost. Additionally, a lost probe packet should not be treated as a signal of congestion. However, these probe packets do consume congestion window, which could delay the transmission of subsequent application data.

-- 
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/3702#discussion_r432463344

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 29 May 2020 06:27:42 -0700

Nearly, could we say:

Probe packets are larger than the current maximum packet size and therefore more likely to be dropped by the network. Endpoints could therefore limit the content of probe packets to ACK-eliciting frames that are not retransmitted (e.g., using PING and PADDING frames).  Loss of a probe packet SHOULD NOT be treated as an indication of congestion and SHOULD NOT trigger a congestion control reaction (see section 3, bullet 7 of {{!DPLPMTUD}}.  However, probe packets do consume congestion window, which could delay subsequent transmission by an application.

-- 
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/3702#discussion_r432481539

---

From: Martin Thomson <[email-masked]>
Date: Sun, 31 May 2020 17:10:00 -0700

@martinthomson pushed 2 commits.

6349e16ca5236d8e489f879a8575ee41aa9c037b  Add suggested text
8f40887e4e248316813db3d6d5d66b18be38379b  Add a term, use it

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3702/files/ad691c836127271e114713893c5b35e20e6f3ad4..8f40887e4e248316813db3d6d5d66b18be38379b

---

From: Martin Thomson <[email-masked]>
Date: Sun, 31 May 2020 17:10:36 -0700

@janaiyengar, I went with "PMTU probe packet", which is an **IP** packet.  Let me know if that makes sense.

-- 
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/3702#issuecomment-636552438

---

From: Jana Iyengar <[email-masked]>
Date: Sun, 31 May 2020 19:57:01 -0700

@janaiyengar commented on this pull request.

Thank you for your changes! I think it might be useful to distinguish the "IP packet" from how we commonly use "packet", so I propose (i) simply use "PMTU probe", and (ii) saying explicitly what that refers to. I've made some suggestions through the text to this end; see what you think.

 The QUIC packet size includes the QUIC header and protected payload, but not the
-UDP or IP header.
+UDP or IP headers.
+
+QUIC depends upon a minimum IP packet size of at least 1280 bytes.  This is the
+IPv6 minimum size {{?RFC8200}} and is also supported by most modern IPv4
+networks.  Assuming the minimum IP header size, this results in a QUIC maximum
+packet size of 1232 bytes for IPv6 and 1252 bytes for IPv4.
+
+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 PMTUD/DPLPMTUD.

expand/cite for PMTUD/DPLPMTUD. I don't think it's been introduced before.

>  An endpoint SHOULD use Datagram Packetization Layer PMTU Discovery
 ({{!DPLPMTUD=I-D.ietf-tsvwg-datagram-plpmtud}}) or implement Path MTU Discovery
 (PMTUD) {{!RFC1191}} {{!RFC8201}} to determine whether the path to a destination

Move this above to where PMTUD and DPLPMTUD are used for the first time.

> +bytes, it MUST immediately cease sending QUIC packets, except for PMTU probe
+packets, on the affected path.  An endpoint MAY terminate the connection if an

```suggestion
bytes, it MUST immediately cease sending QUIC packets, except for those in PMTU
probes, on the affected path.  An endpoint MAY terminate the connection if an
```

> +PMTU probe packets for DPLPMTUD that use the PADDING frame implement "Probing
+using padding data", as defined in Section 4.1 of {{!DPLPMTUD}}.

```suggestion
PMTU probes for DPLPMTUD that use the PADDING frame implement "Probing
using padding data", as defined in Section 4.1 of {{!DPLPMTUD}}.
```

> +Both PMTUD and DPLPMTUD send IP packets that are larger than the current maximum
+packet size.  Aside from these PMTU probe packets, all QUIC packets SHOULD be
+sized to fit within the maximum packet size to avoid the packet being fragmented
+or dropped {{?RFC8085}}.

```suggestion
Both PMTUD and DPLPMTUD send IP packets that are larger than the current maximum
packet size.  We refer to these packets as PMTU probes. All QUIC packets that are not
in a PMTU probe SHOULD be sized to fit within the maximum packet size to avoid the
packet being fragmented or dropped {{?RFC8085}}.
```

>  apply if these messages are used by DPLPMTUD.

-### PMTU Probes Containing Source Connection ID {#pmtu-probes-src-cid}
+## Sending QUIC PMTU Probe Packets
+
+PMTU probe packets are ack-eliciting packets.

```suggestion
PMTU probes contain ack-eliciting packets.
```

>  apply if these messages are used by DPLPMTUD.

-### PMTU Probes Containing Source Connection ID {#pmtu-probes-src-cid}
+## Sending QUIC PMTU Probe Packets
+
+PMTU probe packets are ack-eliciting packets.
+
+Endpoints could limit the content of probe packets to PING and PADDING frames as

```suggestion
Endpoints could limit the content of PMTU probes to PING and PADDING frames as
```

>  apply if these messages are used by DPLPMTUD.

-### PMTU Probes Containing Source Connection ID {#pmtu-probes-src-cid}
+## Sending QUIC PMTU Probe Packets
+
+PMTU probe packets are ack-eliciting packets.
+
+Endpoints could limit the content of probe packets 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 packet is therefore not a reliable indication of congestion and SHOULD NOT

```suggestion
probe is therefore not a reliable indication of congestion and SHOULD NOT
```

> -packets are likely to require that the connection ID be included in PMTU probe
-packets to route any resulting ICMP messages ({{icmp-pmtud}}) back to the
-correct endpoint.  However, only long header packets ({{long-header}}) contain
-source connection IDs, and long header packets are not decrypted or acknowledged
-by the peer once the handshake is complete.
-
-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.
+packets are likely to require that the connection ID be included in
+PMTU probe packets to route any resulting ICMP messages ({{icmp-pmtud}}) back to

```suggestion
PMTU probes to route any resulting ICMP messages ({{icmp-pmtud}}) back to
```

-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.
+packets are likely to require that the connection ID be included in
+PMTU probe packets to route any resulting ICMP messages ({{icmp-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.
+
+One way to construct a PMTU probe packet is to coalesce (see

```suggestion
One way to construct a PMTU probe is to coalesce (see
```

-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.
+packets are likely to require that the connection ID be included in
+PMTU probe packets to route any resulting ICMP messages ({{icmp-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.
+
+One way to construct a PMTU probe packet 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 packet reaches the endpoint, the packet with the

```suggestion
If the resulting PMTU probe reaches the endpoint, the packet with 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.
+packets are likely to require that the connection ID be included in
+PMTU probe packets to route any resulting ICMP messages ({{icmp-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.
+
+One way to construct a PMTU probe packet 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 packet reaches the endpoint, the packet with the
+long header 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

```suggestion
If the PMTU probe causes an ICMP message to be sent, the first part of the
```

-connection ID is within the quoted portion of the UDP datagram, that could be
-used for routing.
+packets are likely to require that the connection ID be included in
+PMTU probe packets to route any resulting ICMP messages ({{icmp-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.
+
+One way to construct a PMTU probe packet 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 packet reaches the endpoint, the packet with the
+long header 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 field is

```suggestion
probe will be quoted in that message.  If the Source Connection ID field is
```

-- 
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/3702#pullrequestreview-421566019

---

From: Martin Thomson <[email-masked]>
Date: Sun, 31 May 2020 22:33:49 -0700

6ba0551df370230e638410d33f48422559d00054  Many more changes based on review

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3702/files/8f40887e4e248316813db3d6d5d66b18be38379b..6ba0551df370230e638410d33f48422559d00054

---

From: Jana Iyengar <[email-masked]>
Date: Sun, 31 May 2020 23:23:00 -0700

@janaiyengar approved this pull request.

-- 
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/3702#pullrequestreview-421617422