DPLPMTU merge tweaks #3702

martinthomson · 2020-05-27T00:34:45Z

This is #3693 with some minor additional changes:

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

Closes #3693.
Closes #3695.

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.

That would be good, the change was unintended. Co-authored-by: ianswett <ianswett@users.noreply.github.com>

I like that:-) Co-authored-by: ianswett <ianswett@users.noreply.github.com>

Co-authored-by: Martin Thomson <mt@lowentropy.net>

This looks good Co-authored-by: ianswett <ianswett@users.noreply.github.com>

This looks good Co-authored-by: Martin Thomson <mt@lowentropy.net>

That would be OK. DPLPMTUD only handles PTB messages. Co-authored-by: Martin Thomson <mt@lowentropy.net>

Co-authored-by: Martin Thomson <mt@lowentropy.net>

Typo fixed. Co-authored-by: Martin Thomson <mt@lowentropy.net>

Fix for /application data/

Seems correct Co-authored-by: Martin Thomson <mt@lowentropy.net>

Typo fix

Understood, and corrected. Co-authored-by: Martin Thomson <mt@lowentropy.net>

Changes to resolve description of probe packets and need to explain the maximum size.

gorryfair

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.

gorryfair · 2020-05-27T08:05:17Z

draft-ietf-quic-transport.md

+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)?

Yep. Missed that in my pass. Corrected.

gorryfair · 2020-05-27T08:08:53Z

draft-ietf-quic-transport.md

+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

Yeah, this should be either.

gorryfair · 2020-05-27T08:19:53Z

draft-ietf-quic-transport.md

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

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.

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.

gorryfair · 2020-05-27T08:26:32Z

draft-ietf-quic-transport.md

@@ -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?

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

gorryfair · 2020-05-27T08:28:49Z

draft-ietf-quic-transport.md

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

gorryfair · 2020-05-27T08:31:08Z

draft-ietf-quic-transport.md

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

gorryfair · 2020-05-27T09:08:30Z

draft-ietf-quic-transport.md

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

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

:-). (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.

gorryfair · 2020-05-27T09:08:49Z

draft-ietf-quic-transport.md

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

We've taken to writing these out in full.

gorryfair · 2020-05-27T09:10:22Z

draft-ietf-quic-transport.md

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

gorryfair · 2020-05-27T09:11:09Z

draft-ietf-quic-transport.md

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

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

…to dplpmtud-merge Integrate latest changes from the source

martinthomson

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

martinthomson · 2020-05-28T01:05:11Z

draft-ietf-quic-transport.md

@@ -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


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

martinthomson · 2020-05-28T01:06:21Z

draft-ietf-quic-transport.md

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


Yep. Missed that in my pass. Corrected.

martinthomson · 2020-05-28T01:08:47Z

draft-ietf-quic-transport.md

+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


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.

martinthomson · 2020-05-28T01:09:34Z

draft-ietf-quic-transport.md

+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 don't think we use is, so thanks for drawing attention to it. We use "connection ID" and so I have fixed this.

martinthomson · 2020-05-28T01:09:50Z

draft-ietf-quic-transport.md

+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


Yeah, this should be either.

martinthomson · 2020-05-28T01:12:37Z

draft-ietf-quic-transport.md

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


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

martinthomson · 2020-05-28T01:12:55Z

draft-ietf-quic-transport.md

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


We've taken to writing these out in full.

janaiyengar

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.

draft-ietf-quic-transport.md

janaiyengar · 2020-05-28T00:31:24Z

draft-ietf-quic-transport.md

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

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.

janaiyengar · 2020-05-28T00:33:17Z

draft-ietf-quic-transport.md

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

janaiyengar · 2020-05-28T01:02:01Z

draft-ietf-quic-transport.md

+
+### 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"?

Works for me.

draft-ietf-quic-transport.md

janaiyengar · 2020-05-28T01:16:27Z

draft-ietf-quic-transport.md

+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


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.

Co-authored-by: Jana Iyengar <jri.ietf@gmail.com>

gorryfair

These look goof to me.

msvoelker · 2020-05-28T15:45:30Z

draft-ietf-quic-transport.md

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

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?

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

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.

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.

martinthomson · 2020-06-01T00:10:16Z

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

janaiyengar

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.

janaiyengar · 2020-06-01T02:39:55Z

draft-ietf-quic-transport.md

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

janaiyengar · 2020-06-01T02:41:18Z

draft-ietf-quic-transport.md

 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.

janaiyengar · 2020-06-01T02:44:53Z

draft-ietf-quic-transport.md

+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


Suggested change

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

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

janaiyengar · 2020-06-01T02:45:39Z

draft-ietf-quic-transport.md

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


Suggested change

PMTU probe packets for DPLPMTUD that use the PADDING frame implement "Probing

using padding data", as defined in Section 4.1 of {{!DPLPMTUD}}.

PMTU probes for DPLPMTUD that use the PADDING frame implement "Probing

using padding data", as defined in Section 4.1 of {{!DPLPMTUD}}.

janaiyengar · 2020-06-01T02:48:57Z

draft-ietf-quic-transport.md

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


Suggested change

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

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

janaiyengar · 2020-06-01T02:53:28Z

draft-ietf-quic-transport.md

-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


Suggested change

PMTU probe packets to route any resulting ICMP messages ({{icmp-pmtud}}) back to

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

janaiyengar · 2020-06-01T02:53:40Z

draft-ietf-quic-transport.md

+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


Suggested change

One way to construct a PMTU probe packet is to coalesce (see

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

janaiyengar · 2020-06-01T02:53:57Z

draft-ietf-quic-transport.md

+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


Suggested change

If the resulting PMTU probe packet reaches the endpoint, the packet with the

If the resulting PMTU probe reaches the endpoint, the packet with the

janaiyengar · 2020-06-01T02:54:26Z

draft-ietf-quic-transport.md

+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


Suggested change

If the UDP datagram causes an ICMP message to be sent, the first part of the

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

janaiyengar · 2020-06-01T02:54:56Z

draft-ietf-quic-transport.md

+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


Suggested change

datagram will be quoted in that message. If the Source Connection ID field is

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

gorryfair · 2020-06-01T08:00:16Z

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.

OK - There are already "IP packets" and "QUIC packets" - so some other term works fro me.

ianswett · 2020-06-01T23:03:22Z

draft-ietf-quic-transport.md

+network path from the client to the server supports a reasonable Path Maximum
+Transmission Unit (PMTU).  This also helps reduce the amplitude of amplification
+attacks caused by server responses toward an unverified client address; see
+{{address-validation}}.

 Enforcement of the max_udp_payload_size transport parameter


I'd move this paragraph above the one above, since they both talk about maximum packet size and in particular this paragraph uses "additional limit" which reads better one paragraph up.

ianswett · 2020-06-01T23:06:29Z

draft-ietf-quic-transport.md

-connection by sending a CONNECTION_CLOSE frame with an error code of
-PROTOCOL_VIOLATION; see {{immediate-close-hs}}.
+A server MUST discard an Initial packet that is carried in a UDP datagram with a
+payload that is less than the smallest allowed maximum packet size  of 1200


Suggested change

payload that is less than the smallest allowed maximum packet size of 1200

payload that is less than the smallest allowed maximum packet size of 1200

ianswett · 2020-06-01T23:10:51Z

draft-ietf-quic-transport.md

+An endpoint SHOULD use DPLPMTUD ({{dplpmtud}}) or PMTUD ({{pmtud}}) to determine
+whether the path to a destination will support a desired message size without
+fragmentation.  In the absence of these mechanisms, QUIC endpoints SHOULD NOT
+send IP packets larger than the minimum QUIC packet size.


Suggested change

send IP packets larger than the minimum QUIC packet size.

send IP packets larger than the smallest allowed maximum packet size.

ianswett · 2020-06-01T23:16:30Z

draft-ietf-quic-transport.md

+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 of 1200
+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


This isn't new text, but tt seems like these two statements may be contradictory? Should this be "except for those in PMTU probes or containing connection close frames, on the affected path."?

ianswett · 2020-06-01T23:36:23Z

draft-ietf-quic-transport.md

+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 on the
+affected path. An endpoint MAY terminate the connection if an alternative path


This seems a bit repetitive of 3862-3866. It's also still confusing or potentially contradictory to me.

The PMTUD one I will add to #3702. The others I don't plan to fix. Closes #3724.

gorryfair · 2020-06-05T12:57:04Z

A top-level comment on the term "probing":
In Section: Probing a New Path: A packet containing only probing frames is a "probing packet", and a packet containing any other frame is a "non-probing packet". Please be sure that "probe" can not be confused with "probing" in PLPMTUD.

gorryfair · 2020-06-05T12:59:07Z

In the subsection on “Packet Size {#packet-size}”, I think the blocks of text describe two things. There is some general guidance on size, and there are specific instructions for the size of the initial packet. I’d suggest we do try to separate these two, it would make it much easier for someone to understand the size constraints for forming the initial packet.

gorryfair · 2020-06-05T13:05:33Z

draft-ietf-quic-transport.md

+network path from the client to the server supports a reasonable Path Maximum
+Transmission Unit (PMTU).  This also helps reduce the amplitude of amplification
+attacks caused by server responses toward an unverified client address; see
+{{address-validation}}.

 Datagrams containing Initial packets MAY exceed 1200 bytes if the client


Needs to be 1200B of payload? (We need to be careful about which layer these numbers are describing, since the datagram itself will be larger.

I think we caught this in #3742.

martinthomson · 2020-06-09T07:17:08Z

Regarding the sizing of Initial packets, see #3746.

I checked the text for probing and we have "PMTUD probe" in one case and "probing packet" elsewhere. It's not ideal, but I didn't see any cases that were clearly busted. I don't have a good idea for alternative labels, but would welcome suggestions.

gorryfair and others added 19 commits May 25, 2020 14:29

Update draft-ietf-quic-transport.md

ec591d1

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.

Update draft-ietf-quic-transport.md

ba44ea7

That would be good, the change was unintended. Co-authored-by: ianswett <ianswett@users.noreply.github.com>

Update draft-ietf-quic-transport.md

0f338c7

I like that:-) Co-authored-by: ianswett <ianswett@users.noreply.github.com>

Update draft-ietf-quic-transport.md

c24e763

Co-authored-by: Martin Thomson <mt@lowentropy.net>

Update draft-ietf-quic-transport.md

230e1f8

This looks good Co-authored-by: ianswett <ianswett@users.noreply.github.com>

Update draft-ietf-quic-transport.md

0fb311b

This looks good Co-authored-by: Martin Thomson <mt@lowentropy.net>

Update draft-ietf-quic-transport.md

02ff34d

This looks good Co-authored-by: Martin Thomson <mt@lowentropy.net>

Update draft-ietf-quic-transport.md

74b760e

This looks good Co-authored-by: Martin Thomson <mt@lowentropy.net>

Update draft-ietf-quic-transport.md

a2cb752

That would be OK. DPLPMTUD only handles PTB messages. Co-authored-by: Martin Thomson <mt@lowentropy.net>

Update draft-ietf-quic-transport.md

7040f72

Co-authored-by: Martin Thomson <mt@lowentropy.net>

Update draft-ietf-quic-transport.md

a12dfdf

Typo fixed. Co-authored-by: Martin Thomson <mt@lowentropy.net>

Update draft-ietf-quic-transport.md

a020020

Update draft-ietf-quic-transport.md

8cf8a46

Fix for /application data/

Update draft-ietf-quic-transport.md

8c185a8

Seems correct Co-authored-by: Martin Thomson <mt@lowentropy.net>

Update draft-ietf-quic-transport.md

acda596

Typo fix

Reflow

fd1d050

Move section back where it belongs

9aa2022

PING AND PADDING are not it

ef1b1c4

Add a number for clarity

1a9c864

martinthomson added design An issue that affects the design of the protocol; resolution requires consensus. -transport labels May 27, 2020

Use long header packets generically and explain why

cbfb4d1

martinthomson mentioned this pull request May 27, 2020

Integrate QUIC text from DPLPMTUD #3693

Closed

gorryfair and others added 2 commits May 27, 2020 08:43

Update draft-ietf-quic-transport.md

0d82ddc

Understood, and corrected. Co-authored-by: Martin Thomson <mt@lowentropy.net>

Update draft-ietf-quic-transport.md

4692d92

Changes to resolve description of probe packets and need to explain the maximum size.

gorryfair reviewed May 27, 2020

View reviewed changes

martinthomson added 4 commits May 28, 2020 09:29

Merge branch 'patch-2' of https://github.com/gorryfair/base-drafts in…

0d20f54

…to dplpmtud-merge Integrate latest changes from the source

Reflow

fef6000

IP packet size is 1280

e01a041

Remove duplicate text

a31a046

martinthomson added 2 commits May 28, 2020 11:06

Remove has 1-RTT key clause as redundant

a9b7969

Editorial comments based on Gorry's feedback

d28c636

martinthomson commented May 28, 2020

View reviewed changes

janaiyengar requested changes May 28, 2020

View reviewed changes

martinthomson and others added 2 commits May 28, 2020 11:31

Remove probing clause

26e301f

Small edits

ad691c8

Co-authored-by: Jana Iyengar <jri.ietf@gmail.com>

gorryfair reviewed May 28, 2020

View reviewed changes

msvoelker reviewed May 28, 2020

View reviewed changes

martinthomson added 2 commits June 1, 2020 10:09

Add suggested text

6349e16

Add a term, use it

8f40887

janaiyengar reviewed Jun 1, 2020

View reviewed changes

Many more changes based on review

6ba0551

janaiyengar approved these changes Jun 1, 2020

View reviewed changes

ianswett approved these changes Jun 1, 2020

View reviewed changes

Editorial tweaks

1cd8875

martinthomson added a commit that referenced this pull request Jun 4, 2020

Use 'message' less

32fc567

The PMTUD one I will add to #3702. The others I don't plan to fix. Closes #3724.

martinthomson mentioned this pull request Jun 4, 2020

Use 'message' less #3726

Merged

Use maximum packet size rather than message size

567b253

gorryfair reviewed Jun 5, 2020

View reviewed changes

martinthomson merged commit 18becf2 into master Jun 9, 2020

martinthomson deleted the dplpmtud-merge branch June 9, 2020 07:20

Ralith mentioned this pull request Jun 29, 2020

Initial support for PLPMTUD quinn-rs/quinn#804

Closed


		### Sending QUIC DPLPMTUD Probe Packets

		DPLPMTU probe packets are ack-eliciting packets. Probe packets that use the

		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

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

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

	One way to construct a PMTU probe packet is to coalesce (see
	One way to construct a PMTU probe is to coalesce (see

	If the resulting PMTU probe packet reaches the endpoint, the packet with the
	If the resulting PMTU probe reaches the endpoint, the packet with the

	If the UDP datagram causes an ICMP message to be sent, the first part of the
	If the PMTU probe 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
	probe will be quoted in that message. If the Source Connection ID field is

	payload that is less than the smallest allowed maximum packet size of 1200
	payload that is less than the smallest allowed maximum packet size of 1200

	send IP packets larger than the minimum QUIC packet size.
	send IP packets larger than the smallest allowed maximum packet size.

DPLPMTU merge tweaks #3702

DPLPMTU merge tweaks #3702

Conversation

martinthomson commented May 27, 2020

gorryfair left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

martinthomson left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

janaiyengar left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gorryfair left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

martinthomson commented Jun 1, 2020

janaiyengar left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gorryfair commented Jun 1, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gorryfair commented Jun 5, 2020

gorryfair commented Jun 5, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

martinthomson commented Jun 9, 2020