Subject: [quicwg/base-drafts] Update draft-ietf-quic-transport.md (#3693)

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 25 May 2020 06:30:56 -0700

This set of changes seeks to:
* Complete the transfer of DPLPMTUD text from the DPLPMTUD-RFC-to-be to this ID.
* Separate PMTUD from DPLPMTUD where they differ.
* Seek consistent language for packet sizes within these sections.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Update draft-ietf-quic-transport.md

-- File Changes --

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

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/3693.patch
https://github.com/quicwg/base-drafts/pull/3693.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/3693

---

From: ianswett <[email-masked]>
Date: Mon, 25 May 2020 11:29:32 -0700

@ianswett commented on this pull request.

Thanks for updating this.  I'm worried there are some unintended changes in this PR, I've found a few so far.

> @@ -3797,17 +3797,23 @@ later time in the connection.
 The QUIC packet size includes the QUIC header and protected payload, but not the
 UDP or IP header.
 
+QUIC defines the minimum QUIC packet size as at least 1280 bytes.

```suggestion
QUIC depends upon a minimum packet size as at least 1280 bytes.
```

>  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
+to at least the minimum QUIC packet size, by adding PADDING frames to the Initial packet or by

Keep this as 1200 bytes.

```suggestion
to at least 1200 bytes, by adding PADDING frames to the Initial packet or by
```

>  In the absence of these mechanisms, QUIC endpoints SHOULD NOT send IP packets
-larger than 1280 bytes. Assuming the minimum IP header size, this results in a
-QUIC maximum packet size of 1232 bytes for IPv6 and 1252 bytes for IPv4. A QUIC
-implementation MAY be more conservative in computing the QUIC maximum packet
-size to allow for unknown tunnel overheads or IP header options/extensions.
+larger than the minimum QUIC packet size. 
+
+All QUIC
+packets (except for PMTUD/DPLPMTUD probe packets) SHOULD be sized to fit within the
+maximum packet size to avoid the packet being fragmented or dropped
+{{?RFC8085}}.
+
+If a QUIC endpoint determines that the PMTU between any pair of local and remote
+IP addresses has fallen below the minimum QUIC packet size, it MUST immediately 

Please keep the existing wording of "smallest allowed maximum packet size", since that's very different from the minimum QUIC packet size.

```suggestion
IP addresses has fallen below the smallest allowed maximum packet size, it MUST immediately 
```

-- 
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/3693#pullrequestreview-417836536

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 25 May 2020 12:37:44 -0700

@gorryfair pushed 1 commit.

ba44ea7b3307f7da99be88c516270b9c008c78e7  Update draft-ietf-quic-transport.md

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

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 25 May 2020 12:38:14 -0700

0f338c711ebc8cd40a54410e73938f592a28ab87  Update draft-ietf-quic-transport.md

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

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 25 May 2020 12:38:41 -0700

@gorryfair commented on this pull request.

Fine, except shouldn't this be: /as at/of at/

-- 
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/3693#discussion_r430056597

---

From: Martin Thomson <[email-masked]>
Date: Mon, 25 May 2020 18:16:37 -0700

@martinthomson commented on this pull request.

Thanks for making a concrete proposal.  It really helps to have it written out.

I have a bunch of suggestions, but I don't see any real barrier to including this text on the basis of this PR.

Don't worry about the CI build failures.  This will need some cleanup, but I can do that fairly easily.  Let's get the text right first.

This is a major change, so I'll be opening an issue to track this.  In a sense, it's editorial because we are only taking text that we previously normatively referenced, but it's big enough to track properly.  Besides, I think that I suggested some substantive changes and I would be sad to see those not included.

```suggestion
packets other than PMTUD/DPLPMTUD probe packets SHOULD be sized to fit within the
```

-## ICMP Packet Too Big Messages {#icmp-pmtud}
+### Handling of ICMP PTB Messages by PMTUD {#icmp-pmtud}

I would drop PTB from this.  It's already alphabet soup, but this is also accurate:

```suggestion
### Handling of ICMP Messages by PMTUD {#icmp-pmtud}
```

If you are looking for a proper parallel construction, then maybe consider just making this the PMTUD section:

```suggestion
## PMTU Discovery {#icmp-pmtud}
```

>  (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.
 
 An endpoint MUST ignore an ICMP message that claims the PMTU has decreased below
-1280 bytes.
+the minimum QUIC packet size bytes.

```suggestion
the minimum QUIC packet size.
```

>  as specified in {{!RFC8201}} and Section 5.2 of {{!RFC8085}}. This validation
 SHOULD use the quoted packet supplied in the payload of an ICMP message to
-associate the message with a corresponding transport connection {{!DPLPMTUD}}.
-
+associate the message with a corresponding transport connection (e.g., {{!DPLPMTUD}}).

I appreciate the correction of the citation here, but I am not getting the connection still.  Do you have a specific citation in DPLPMTUD that would support this?  Maybe:

```suggestion
associate the message with a corresponding transport connection; see Section X.X
of {{!DPLPMTUD}}.
```

or 
```suggestion
associate the message with a corresponding transport connection; for instance,
Section X.X of {{!DPLPMTUD}} describes Y.
```

> +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 terminate the connection if an alternative
+path cannot be found.
+
+###  DPLPMTUD and Initial Connectivity
+
+From the perspective of DPLPMTUD, QUIC transport is an 
+acknowledged PL. A sender can therefore enter the DPLPMTUD BASE

Expand on first use please.  More so because this acronym is used only once here.

```suggestion
acknowledged packetization layer (PL). A sender can therefore enter the DPLPMTUD BASE
```

-The considerations for processing ICMP messages in the previous section also
+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. 

Missing paragraph break.
```suggestion
addresses.

```

> +QUIC endpoints implementing DPLPMTUD maintain a maximum packet size 
+(DPLPMTUD MPS) for each combination of local and remote IP
+addresses. 

Is this a path property?  Because this could be "pair of local and remote addresses" (strike the IP) and then it would include port numbers too.  That is likely more general.

> +state when the QUIC connection handshake has been completed and
+the endpoint has established a 1-RTT key.

Is it necessary for this to happen so late?  I see some implementations probing much earlier than that.  Also, this definition is a new state.  We have "handshake completed", but 1-RTT keys are established earlier than that.  I would just say "handshake completed" and leave it at that.

```suggestion
state when the QUIC connection handshake is complete.
```

> +DPLPMTU Probe packets consists of a QUIC Header and a payload containing a
+PING Frame and multiple PADDING Frames, this can implement
+"Probing using padding data" (see section 4.1 of {{!DPLPMTUD}}. 

This is too narrowly restrictive. I would instead say:

```suggestion
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}}.
```

> +These can be generated without affecting the transfer of other QUIC frames.
+The PING Frame is used to trigger generation of an acknowledgement.
+Multiple PADDING Frames are used together to control the length of the probe packet.  

Again, too prescriptive.

```suggestion
```

> +These frames might not be retransmitted if a probe packet containing
+them is lost.  The frames consume congestion window,
+which could delay the transmission of subsequent application data.

This is incorrect.  PADDING and PING are not retransmitted on loss.  The fact that they are ack-eliciting causes them to consume congestion window, but this is less of a problem if they include other data.  Which they may well do (albeit with a higher risk of that data needing retransmission).

```suggestion

DPLPMTUD probe packets consume congestion window, so they could delay
the transmission of subsequent application.
```

> +DPLPMTU Probe packets consists of a QUIC Header and a payload containing a
+PING Frame and multiple PADDING Frames, this can implement
+"Probing using padding data" (see section 4.1 of {{!DPLPMTUD}}. 
+These can be generated without affecting the transfer of other QUIC frames.
+The PING Frame is used to trigger generation of an acknowledgement.
+Multiple PADDING Frames are used together to control the length of the probe packet.  
+These frames might not be retransmitted if a probe packet containing
+them is lost.  The frames consume congestion window,
+which could delay the transmission of subsequent application data.
+
+###  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 PTB Messages by DPLPMTUD

```suggestion
###  Handling of ICMP Messages by DPLPMTUD
```

> +which could delay the transmission of subsequent application data.
+
+###  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 PTB 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
+quoted packet of any received ICMP message). 
+The further considerations for processing ICMP messages described in the previous section also

```suggestion

The considerations for processing ICMP messages described in {{icmp-pmtud}} also
```

>  The endpoint SHOULD ignore all ICMP messages that fail validation.
 
 An endpoint MUST NOT increase PMTU based on ICMP messages; see Section 3, clause
 6 of {{!DPLPMTUD}}.  Any reduction in the QUIC maximum packet size in response
 to ICMP messages MAY be provisional until QUIC's loss detection algorithm
 determines that the quoted packet has actually been lost.
 
+### PMTUD Probes with Handshake packets

Please move this back.  It belongs where it was taken from.

I realize that you now have a section for PMTUD parallel to the section for PLPMTUD, and this allows you to make the structure cleaner (with two subsections and not one, which I agree is nice), but this text is relevant to both.

(I think that this move points out that the specific use of Handshake isn't the ideal. Though Initial packets might be a bad idea, using 0-RTT is also fine.)

-- 
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/3693#pullrequestreview-417911791

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 26 May 2020 00:10:21 -0700

c24e763e0616a78737f90f0d79ba6f347e932267  Update draft-ietf-quic-transport.md

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

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 26 May 2020 00:10:49 -0700

230e1f862eb346465fa1fd40fb5ce633f7bccb86  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3693/files/c24e763e0616a78737f90f0d79ba6f347e932267..230e1f862eb346465fa1fd40fb5ce633f7bccb86

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 26 May 2020 00:11:10 -0700

0fb311b06a096670e11a8cf0db1e41e2c6a68b4c  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3693/files/230e1f862eb346465fa1fd40fb5ce633f7bccb86..0fb311b06a096670e11a8cf0db1e41e2c6a68b4c

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 26 May 2020 00:11:58 -0700

02ff34d3a97eaea87dbe9a181d7a6896b276f014  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3693/files/0fb311b06a096670e11a8cf0db1e41e2c6a68b4c..02ff34d3a97eaea87dbe9a181d7a6896b276f014

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 26 May 2020 00:12:23 -0700

74b760e7799b0d73a770e830a1fe52b80924f9e7  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3693/files/02ff34d3a97eaea87dbe9a181d7a6896b276f014..74b760e7799b0d73a770e830a1fe52b80924f9e7

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 26 May 2020 00:16:46 -0700

a2cb752e4d5c75dfa4a452c06f5bdb19e66fe891  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3693/files/74b760e7799b0d73a770e830a1fe52b80924f9e7..a2cb752e4d5c75dfa4a452c06f5bdb19e66fe891

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 26 May 2020 00:20:08 -0700

The initial sentence was already there - I thought it added nothing, so happy to see that removed. 
The fix to the second sentence is broken, but I think this might be /could delay subsequent transmission by the 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/3693#discussion_r430204334

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 26 May 2020 00:28:08 -0700

So, the idea of sending a larger probe before the connection is established is something that probably needs more discussion for both cases.

-- 
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/3693#discussion_r430208324

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 26 May 2020 00:29:02 -0700

7040f72f466e1bf371a1c47c63a427ad34ccbd38  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3693/files/a2cb752e4d5c75dfa4a452c06f5bdb19e66fe891..7040f72f466e1bf371a1c47c63a427ad34ccbd38

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 26 May 2020 00:43:18 -0700

I'd prefer "see Section 4.6.1 of {{!DPLPMTUD}}."

-- 
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/3693#discussion_r430216051

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 26 May 2020 00:44:14 -0700

a12dfdf2da7ab759a3866ac0d2a82f4ad8eea650  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3693/files/7040f72f466e1bf371a1c47c63a427ad34ccbd38..a12dfdf2da7ab759a3866ac0d2a82f4ad8eea650

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 26 May 2020 00:45:31 -0700

This text was proposed by Magnus in a tsvwg thread. We should discuss this.

-- 
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/3693#discussion_r430217317

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 26 May 2020 00:47:55 -0700

Looks OK, the text needs at least to 
(1) describe how to construct a probe packet
(2) explain if the probe packet can carry data or only padding.

-- 
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/3693#discussion_r430218654

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 26 May 2020 02:14:37 -0700

@gloinul commented on this pull request.

Some feedback on the text. 

+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. 

Should there be an addition to the "QUIC maximum packet size" like initial or base line to indicate that the QUIC maximum packet size is actually a variable that can be changed by the PMTUD/DPLPMTUD? 

-larger than 1280 bytes. Assuming the minimum IP header size, this results in a
-QUIC maximum packet size of 1232 bytes for IPv6 and 1252 bytes for IPv4. A QUIC
-implementation MAY be more conservative in computing the QUIC maximum packet
-size to allow for unknown tunnel overheads or IP header options/extensions.
+larger than the minimum QUIC packet size. 
+
+All QUIC
+packets other than PMTUD/DPLPMTUD probe packets SHOULD be sized to fit within the
+maximum packet size to avoid the packet being fragmented or dropped
+{{?RFC8085}}.
+
+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, it MUST immediately 

Isn't the "smallest allowed maximum packt size" equal to the "minimum QUIC packet size"? I guess strictly not, as smallest allowed maximum packet size is on IP level which is 1280. While "minimum QUIC packet size" based on the initial requirement is 1200 bytes and results in a IP level value that is slightly less than 1280. I think this needs some alignment. Maybe basing it on the 1200 bytes minimum QUIC packet size and say that smallest supported Maximum Packet Size is then 1200 plus overhead for IP/UDP. 

So, this was an attempt from me to correct something that looked even more broken in the earlier text in the TSVWG document. If handshake is complete is a good term lets use it. 

So I think it is relevant to at least go through the implication of sending DPLPMTUD probes prior to handshake complete. So one possible implementation here could be to first send your initial packet with 1280 as MPS. Then you use the rest of your IW=10 to send a broad side of Path MTU probes of various sizes checking a number of common sizes up to the client's local interface's MPS. So in relation to recovery that defines the initial window to 10*max_datagram_size with a limit of max (14720, 2*max_datagram_size). I make an assumption that one will in this case start with max_datagram_size=1200. Thus one can fit some number of probes. So allow DPLPMTUD to use 0-RTT keys to send probes I think is likely to result that the client to server handshake flight will often contain 10-12k of data even if there are no 0-RTT application data. That might be a good investment, but I are we certain of the DoS properties of this? 

So my though was simply to be a bit conservative here and ensure that both endpoints know there are someone there that will report delivery of the probes before sending them. But, this is clearly something the QUIC WG can discuss and change. 

-- 
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/3693#pullrequestreview-418084163

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 26 May 2020 02:24:49 -0700

I like clarity about constants and variables, the text in DPLPMTUD says: "The Maximum Packet Size (MPS) is the largest size of application data block that can be sent across a network path by a PL using a single Datagram.", so for QUIC, maybe this could read: 
"The QUIC maximum packet size is the largest size of QUIC packet that can be sent across a network path using a single packet. This is discovered using PMTUD/DPLPMTUD"?

-- 
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/3693#discussion_r430276044

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 26 May 2020 02:40:48 -0700

See later.

On 26/05/2020 10:14, Magnus Westerlund wrote:
>
> *@gloinul* commented on this pull request.
>
> ------------------------------------------------------------------------
>
> In draft-ietf-quic-transport.md 
> <https://github.com/quicwg/base-drafts/pull/3693#discussion_r430246749>:
>
> Should there be an addition to the "QUIC maximum packet size" like 
> initial or base line to indicate that the QUIC maximum packet size is 
> actually a variable that can be changed by the PMTUD/DPLPMTUD?
>
> ------------------------------------------------------------------------
>
> In draft-ietf-quic-transport.md 
> <https://github.com/quicwg/base-drafts/pull/3693#discussion_r430255170>:
>
> Isn't the "smallest allowed maximum packt size" equal to the "minimum 
> QUIC packet size"? I guess strictly not, as smallest allowed maximum 
> packet size is on IP level which is 1280. While "minimum QUIC packet 
> size" based on the initial requirement is 1200 bytes and results in a 
> IP level value that is slightly less than 1280. I think this needs 
> some alignment. Maybe basing it on the 1200 bytes minimum QUIC packet 
> size and say that smallest supported Maximum Packet Size is then 1200 
> plus overhead for IP/UDP.
>
> ------------------------------------------------------------------------
>
> In draft-ietf-quic-transport.md 
> <https://github.com/quicwg/base-drafts/pull/3693#discussion_r430269451>:
>
> So, this was an attempt from me to correct something that looked even 
> more broken in the earlier text in the TSVWG document. If handshake is 
> complete is a good term lets use it.
>
> So I think it is relevant to at least go through the implication of 
> sending DPLPMTUD probes prior to handshake complete. So one possible 
> implementation here could be to first send your initial packet with 
> 1280 as MPS. Then you use the rest of your IW=10 to send a broad side 
> of Path MTU probes of various sizes checking a number of common sizes 
> up to the client's local interface's MPS. So in relation to recovery 
> that defines the initial window to 10/max_datagram_size with a limit 
> of max (14720, 2/max_datagram_size). I make an assumption that one 
> will in this case start with max_datagram_size=1200. Thus one can fit 
> some number of probes. So allow DPLPMTUD to use 0-RTT keys to send 
> probes I think is likely to result that the client to server handshake 
> flight will often contain 10-12k of data even if there are no 0-RTT 
> application data. That might be a good investment, but are we certain 
> of the DoS properties of this?
>
> So my though was simply to be a bit conservative here and ensure that 
> both endpoints know there are someone there that will report delivery 
> of the probes before sending them. But, this is clearly something the 
> QUIC WG can discuss and change.
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub 
> <https://github.com/quicwg/base-drafts/pull/3693#pullrequestreview-418084163>, 
> or unsubscribe 
> <https://github.com/notifications/unsubscribe-auth/ABYLLESDHHRZ3EADW6P2ODLRTOB7JANCNFSM4NJQ432A>.
>
The reason why we didn't suggest this within DPLPMTUD, was two things:

* Using the limited for IW for packet probes rapidly consumes the 
current IW space in bytes, and we were unconvinced of the importance to 
tenatively try a large PMTU during the first RTT.

* I was not aware of measurement data about how changing the initial 
flight of data would impact congestion collapse, since at this point 
there is no feedback from the receiver, and it seems, at least to me, to 
raise questions regarding stability with large numbers of flows and also 
as you note, the potential DoS opportunities.

So, I'd be interested in what people think about this, and see any 
analysis and experience.

Gorry

-- 
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/3693#issuecomment-633921344

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 26 May 2020 07:32:04 -0700

a020020e5944ff9a73d3b69ca3bfef65898660b7  Update draft-ietf-quic-transport.md

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

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 26 May 2020 07:34:43 -0700

8cf8a460a958032861b5d04bec80585759eb8633  Update draft-ietf-quic-transport.md

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

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 26 May 2020 07:37:45 -0700

Would you be happy replacing this with /A PING Frame can be used to trigger generation of an acknowledgement to the packet probe./

-- 
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/3693#discussion_r430462604

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 26 May 2020 07:55:04 -0700

8c185a83bdf3a07328737c231f2420480444f9bf  Update draft-ietf-quic-transport.md

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

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 26 May 2020 07:56:37 -0700

acda596362122e5239713c1d3d24531f20d6ef5a  Update draft-ietf-quic-transport.md

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

---

From: Martin Thomson <[email-masked]>
Date: Tue, 26 May 2020 15:13:11 -0700

That's already implied by "ack-eliciting".

-- 
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/3693#discussion_r430736533

---

From: Martin Thomson <[email-masked]>
Date: Tue, 26 May 2020 15:13:52 -0700

This is not about when, but how.  You can send a bogus Handshake packet after the connection is 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/3693#discussion_r430736781

---

From: Martin Thomson <[email-masked]>
Date: Tue, 26 May 2020 16:46:30 -0700

Updated the broken text.

-- 
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/3693#discussion_r430767210

---

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

I'm happy with either, as I said.

-- 
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/3693#discussion_r430767384

---

From: Martin Thomson <[email-masked]>
Date: Tue, 26 May 2020 16:47:53 -0700

I could live with that.

-- 
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/3693#discussion_r430767588

---

From: Martin Thomson <[email-masked]>
Date: Tue, 26 May 2020 16:48:49 -0700

I think that Gorry's changes (recognizing the minimum on MPS in DPLPMTUD) are OK, but I would add "of 1200 bytes" for clarity.

-- 
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/3693#discussion_r430767872

---

From: Martin Thomson <[email-masked]>
Date: Tue, 26 May 2020 16:49:59 -0700

@gorryfair replies (below, repeated to keep the thread intact):

> * Using the limited for IW for packet probes rapidly consumes the current IW space in bytes, and we were unconvinced of the importance to tenatively try a large PMTU during the first RTT.
> 
> * I was not aware of measurement data about how changing the initial flight of data would impact congestion collapse, since at this point there is no feedback from the receiver, and it seems, at least to me, to raise questions regarding stability with large numbers of flows and also as you note, the potential DoS opportunities.
>
> So, I'd be interested in what people think about this, and see any analysis and experience.

-- 
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/3693#discussion_r430768205

---

From: Martin Thomson <[email-masked]>
Date: Tue, 26 May 2020 16:57:05 -0700

I think that the intent of the text is fine, I was only concerned about the execution, purely from a logical standpoint.  That is, `(handshake complete) && (got 1-RTT keys) == (handshake complete)` because `(got 1-RTT keys)` is a precondition for `(handshake complete)`.

As you both say, there are concerns with probing before this point.  Maybe you can, and indeed it is probably beneficial.  But maybe it is also risky, and we don't need that.  If anyone does want to probe before this point, they are off the books for now.  If anyone wants to explicitly allow that in the draft, that's a design change that needs support, justification, and a separate issue to track.  I don't think we can do that as part of this change.

-- 
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/3693#discussion_r430770249

---

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

@martinthomson approved this pull request.

Though there are maybe a few tweaks left (and I need to do a thorough cleanup), I'm happy with this in its current state.

-- 
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/3693#pullrequestreview-418756489

---

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

OK - Can we say that explicitly? 

-- 
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/3693#discussion_r430899311

---

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

Please take a look at #3702 for a proposed tweak.

-- 
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/3693#discussion_r430906382

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 27 May 2020 00:43:46 -0700

0d82ddcf5def2a4c3cc72d31384d302a1e7cd4dc  Update draft-ietf-quic-transport.md

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

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 27 May 2020 00:48:56 -0700

4692d921098e16403fb2406aca767a5d1475520b  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3693/files/0d82ddcf5def2a4c3cc72d31384d302a1e7cd4dc..4692d921098e16403fb2406aca767a5d1475520b

---

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

This seems like the best direction to me - I leave to you whether (got 1-RTT keys) needs to be mentioned as not, and included that in your PR in case you wish to edit (or not).

-- 
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/3693#discussion_r430987519

---

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

Gorry, I have integrated the changes you recently made (all good ones) in #3702.  And as long as you are happy with that, then we can close this and use that instead.

Then all we need to do is give others a chance to comment.  Given the state of this, I'm happy to handle comments (that's the true cost of moving to the other PR).

-- 
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/3693#issuecomment-635001726