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

From: Tom Jones <[email-masked]>
Date: Wed, 21 Nov 2018 06:39:38 -0800

Rewrite Packet Size section to make it clearer and to consider ICMP
handling and Datagram PLPMTUD.

- Add normative reference to DPLPMTUD
- Define MPS as the largest UDP Payload that can safely sent right now
- Improved desctription of IPv4 and IPv6 protocols.
- Discuss port numbers and connection ids as a method for verifying ICMP messages
- Separation of ICMP processing from the method: PMTUD or PLPMTUD
- Replace PLPMTUD considerations with DPLPMTUD considerations
- Specify that probes can made from Packets carrying PING and PADDING frames
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Use DPLPMTUD rather than PLPMTUD
  * Rewrite Packet Size section
  * Merge branch 'master' into uoa/dplpmtu
  * Clean up whitespace

-- File Changes --

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

-- Patch Links --

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

---

From: Nick Banks <[email-masked]>
Date: Wed, 21 Nov 2018 16:36:04 +0000 (UTC)

nibanks approved this pull request.

Generally looks good to me.

> -The PADDING frame provides a useful option for PMTU probe packets. PADDING
-frames generate acknowledgements, but they need not be delivered reliably. As a
-result, the loss of PADDING frames in probe packets does not require
-delay-inducing retransmission. However, PADDING frames do consume congestion
-window, which may delay the transmission of subsequent application data.
-
-When implementing the algorithm in Section 7.2 of {{!PLPMTUD}}, the initial
-value of search_low SHOULD be consistent with the IPv6 minimum packet size.
-Paths that do not support this size cannot deliver Initial packets, and
-therefore are not QUIC-compliant.
-
-Section 7.3 of {{!PLPMTUD}} discusses trade-offs between small and large
-increases in the size of probe packets. As QUIC probe packets need not contain
-application data, aggressive increases in probe size carry fewer consequences.
-
+larger than 1280 bytes (assuming the minimum IP header size).  This results in

I feel like this `(assuming the minimum IP header size)` should be moved to the end of the following sentence instead of here.

> +Each pair of local and remote addresses could have a different PMTU.  QUIC
+implementations that implement any kind of PMTU discovery therefore SHOULD
+maintain a MPS for each combination of local and remote IP addresses.
+
+If a QUIC endpoint determines that the PMTU between any pair of local and
+remote IP addresses has fallen below the size needed to support the smallest
+allowed MPS, it MUST immediately cease sending QUIC packets on the
+affected path.  This could result in termination of the connection if an
+alternative path cannot be found.
+
+### Processing ICMP Messages to reduce the PMTU {#icmp-pmtud}
+
+PMTU discovery {{!RFC1191}} {{!RFC8201}} relies on reception of ICMP messages
+(e.g., IPv6 Packet Too Big, PTB, messages) that indicate when a packet is
+dropped because it is larger than the local router MTU. DPLPMTUD can also
+optionally utilise these messages.  This use of ICMP messages is

```suggestion
optionally utilize these messages.  This use of ICMP messages is
```

> +
+### Processing ICMP Messages to reduce the PMTU {#icmp-pmtud}
+
+PMTU discovery {{!RFC1191}} {{!RFC8201}} relies on reception of ICMP messages
+(e.g., IPv6 Packet Too Big, PTB, messages) that indicate when a packet is
+dropped because it is larger than the local router MTU. DPLPMTUD can also
+optionally utilise these messages.  This use of ICMP messages is
+potentially vulnerable to off-path attacks that successfully guess the IP
+address 3-tuple and reduce the PMTU to a bandwidth-inefficient value
+{{!RFC8201}}.
+
+QUIC endpoints SHOULD provide validation to protect from off-path injection of
+ICMP messages as specified in {{!RFC8201}} and Section 5.2 of {{!RFC8085}}.
+This uses the quoted packet supplied in the payload of an ICMP message, which,
+when present, can be used to associate the message with a corresponding
+transport connection {{!DPLPMTUD}}.

Is it acceptable that a man-on-the-side could use received packets to spoof the ICMP messages?

> +that connection ID information corresponds to an active session.
+
+Further validation can also be provided:
+
+* An IPv4 endpoint could set the Don't Fragment (DF) bit on a small proportion
+  of packets, so that most invalid ICMP messages arrive when there are no DF
+  packets outstanding, and can therefore be identified as spurious.
+
+* An endpoint could store additional information from the IP or UDP headers to
+  use for validation (for example, the IP ID or UDP checksum).
+
+The endpoint SHOULD ignore all ICMP messages that are not validated or do not
+carry sufficient quoted packet payload to perform validation.  Any reduction in
+the QUIC MPS MAY be provisional until QUIC's loss detection algorithm
+determines that the quoted packet has actually been lost.
+

Since there should be enough quoted text to decode the packet number of the QUIC packet, you could save a hash/checksum of the first X bytes of the QUIC packet and validate that matches. 

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

---

From: Dmitri Tikhonov <[email-masked]>
Date: Wed, 21 Nov 2018 16:58:33 +0000 (UTC)

dtikhonov commented on this pull request.

@nibanks, is there a consensus to utilize American English?

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

---

From: Nick Banks <[email-masked]>
Date: Wed, 21 Nov 2018 17:02:26 +0000 (UTC)

nibanks commented on this pull request.

No clue. I think in general it is used, but I have no idea if there is any consensus or requirement. It was just a suggestion. Feel free to ignore.

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

---

From: Mike Bishop <[email-masked]>
Date: Wed, 21 Nov 2018 10:11:53 -0800

MikeBishop commented on this pull request.

-## Path Maximum Transmission Unit
+The PMTU is the maximum size of the entire IP datagram including the IP header,
+UDP header, and UDP payload.  The UDP payload includes the QUIC packet header,
+protected payload, and any authentication fields. This can be depend upon the

```suggestion
protected payload, and any authentication fields. This can depend upon the
```

-## Path Maximum Transmission Unit
+The PMTU is the maximum size of the entire IP datagram including the IP header,
+UDP header, and UDP payload.  The UDP payload includes the QUIC packet header,
+protected payload, and any authentication fields. This can be depend upon the
+current path characteristics.  Therefore, the current largest UDP payload an
+implementation will send is referred to as QUIC Maximum Packet Size (MPS).

Do we need a new defined-and-capitalized term for this? Is there a reason this would be different from "current estimated PMTU"?

-The Path Maximum Transmission Unit (PMTU) is the maximum size of the entire IP
-header, UDP header, and UDP payload. The UDP payload includes the QUIC packet
-header, protected payload, and any authentication fields.
+QUIC depends on a PMTU of at least 1280 bytes. This is the IPv6 minimum size
+{{!RFC8200}} and is also supported by most modern IPv4 networks.  All QUIC
+packets (except for PMTU probe packets) SHOULD be sized to fit within the MPS
+to avoid IP fragmentation or packet drop along the path {{!RFC8805}.

"to avoid packet drop" feels like it's missing a word, or at least a letter.  "to avoid packet drops"?  Seems a little colloquial, but if it's accurate, maybe.  "to avoid the packet being fragmented or dropped", perhaps?

RFC7322:
> The RFC publication language is English.  Spelling may be either American or British, as long as an individual document is internally consistent.  Where both American and British English spelling are used within a document or cluster of documents, the text will be modified to be consistent with American English spelling.

+

That guards against an ICMP message that's wholly fabricated, but not against the man-on-the-side attack.  If the attacker legitimately saw a packet, the only way you detect the attack is when the peer acks the supposedly-too-big packet.

Unfortunately, the best security we have when trying to confirm that a message came from someone on path is that it saw the packet.  We should be wary of believing such unauthenticated messages blindly, however -- this might instead be a signal to re-do PMTUD, or as noted below, be a provisional signal until the packet is independently declared lost.

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

---

From: Mike Bishop <[email-masked]>
Date: Wed, 21 Nov 2018 10:25:44 -0800

@MikeBishop pushed 1 commit.

562ae55  Fix build breaks

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2036/files/513358498dd51015057b4ed0c70ba7382c903df3..562ae5566b0b707913b323eb874d8cc271f2ea15

---

From: Martin Thomson <[email-masked]>
Date: Wed, 21 Nov 2018 16:12:52 -0800

martinthomson commented on this pull request.

Editorial comments for the most part.  This looks like an improvement.

@igorlord, @martinduke, this is something you have shown interest in.  Could you review?

Yes, please use words.  We set the bar high for new definitions and acronyms, because they tend to make the document less readable.  I'm not sure that we even need this concept to be introduced.

We've used "IP packet" throughout, consistent with the IP RFCs.

```suggestion
The PMTU is the maximum size of the entire IP packet including the IP header,
```

```suggestion
larger than 1280 bytes. Assuming the minimum IP header size, this results in
```

```suggestion
optionally use these messages.  This use of ICMP messages is
```

Don't overutilize "utilize".

FWIW, I think that for this document, we have chosen to use American English, even though that is the inferior variant.

> +unknown tunnel overheads or IP header options/extensions.
+

```suggestion
(e.g., IPv6 Packet Too Big messages) that indicate when a packet is
```

+address 3-tuple and reduce the PMTU to a bandwidth-inefficient value
+{{!RFC8201}}.
+
+QUIC endpoints SHOULD provide validation to protect from off-path injection of
+ICMP messages as specified in {{!RFC8201}} and Section 5.2 of {{!RFC8085}}. This
+uses the quoted packet supplied in the payload of an ICMP message, which, when
+present, can be used to associate the message with a corresponding transport
+connection {{!DPLPMTUD}}.
+
+The IPv4 Router requirements {{!RFC1812} state that the quoted packet should
+contain as much of the original datagram as possible without the length of the
+ICMP datagram exceeding 576 bytes. IPv6 routers include as much of invoking
+packet as possible without the ICMPv6 packet exceeding 1280 bytes {{!RFC4443}}.
+The size of the quoted packet can actually be smaller, or the information
+unintelligible, for various reasons {{!DPLPMTUD}}.

A section reference would be useful here.

+
+QUIC endpoints SHOULD provide validation to protect from off-path injection of
+ICMP messages as specified in {{!RFC8201}} and Section 5.2 of {{!RFC8085}}. This
+uses the quoted packet supplied in the payload of an ICMP message, which, when
+present, can be used to associate the message with a corresponding transport
+connection {{!DPLPMTUD}}.
+
+The IPv4 Router requirements {{!RFC1812} state that the quoted packet should
+contain as much of the original datagram as possible without the length of the
+ICMP datagram exceeding 576 bytes. IPv6 routers include as much of invoking
+packet as possible without the ICMPv6 packet exceeding 1280 bytes {{!RFC4443}}.
+The size of the quoted packet can actually be smaller, or the information
+unintelligible, for various reasons {{!DPLPMTUD}}.
+
+When a randomized source port is used, this can provide some protection from

This could be read to imply that PMTUD probes could use a different source port.  That can have the effect of hitting a different path.  This probably needs to be qualified.

+  use for validation (for example, the IP ID or UDP checksum).
+
+The endpoint SHOULD ignore all ICMP messages that are not validated or do not
+carry sufficient quoted packet payload to perform validation.  Any reduction in
+the QUIC MPS MAY be provisional until QUIC's loss detection algorithm
+determines that the quoted packet has actually been lost.
+
+## Considerations for Datagram Packetization Layer PMTU Discovery
+
+Section 6.4 of {{!DPLPMTUD}} provides considerations for
+implementing Datagram Packetization Layer PMTUD (DPLPMTUD) with QUIC.
+
+When implementing the algorithm in Section 5.3 of
+{{!DPLPMTUD}}, the initial value of BASE_PMTU SHOULD be
+consistent with the minimum QUIC packet size.

Saying what that is (1280, I assume, without reading DPLPMTUD) would be helpful.

+The endpoint SHOULD ignore all ICMP messages that are not validated or do not
+carry sufficient quoted packet payload to perform validation.  Any reduction in
+the QUIC MPS MAY be provisional until QUIC's loss detection algorithm
+determines that the quoted packet has actually been lost.
+
+## Considerations for Datagram Packetization Layer PMTU Discovery
+
+Section 6.4 of {{!DPLPMTUD}} provides considerations for
+implementing Datagram Packetization Layer PMTUD (DPLPMTUD) with QUIC.
+
+When implementing the algorithm in Section 5.3 of
+{{!DPLPMTUD}}, the initial value of BASE_PMTU SHOULD be
+consistent with the minimum QUIC packet size.
+
+A PADDING frame can be used to generate PMTU probe packets. PADDING need not be

PADDING frames are not retransmitted if the packet they are contained in is lost.

> +larger than 1280 bytes (assuming the minimum IP header size).  This results in
+a QUIC MPS of 1232 bytes for IPv6 and 1252 bytes for IPv4. A QUIC
+implementation MAY be more conservative in computing the QUIC MPS to allow for
+unknown tunnel overheads or IP header options/extensions.
+
+Each pair of local and remote addresses could have a different PMTU.  QUIC
+implementations that implement any kind of PMTU discovery therefore SHOULD
+maintain a MPS for each combination of local and remote IP addresses.
+
+If a QUIC endpoint determines that the PMTU between any pair of local and
+remote IP addresses has fallen below the size needed to support the smallest
+allowed MPS, it MUST immediately cease sending QUIC packets on the
+affected path.  This could result in termination of the connection if an
+alternative path cannot be found.
+
+### Processing ICMP Messages to reduce the PMTU {#icmp-pmtud}

```suggestion
### Processing ICMP Packet Too Big Messages {#icmp-pmtud}
```

or just

```suggestion
### ICMP Packet Too Big Messages {#icmp-pmtud}
```

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

---

From: Tom Jones <[email-masked]>
Date: Thu, 22 Nov 2018 01:51:51 -0800

@adventureloop pushed 1 commit.

0c88ff5  Apply suggestions from code review

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2036/files/562ae5566b0b707913b323eb874d8cc271f2ea15..0c88ff5d4e8d353f86b2cb767cee9008b8bd6f87

---

From: Tom Jones <[email-masked]>
Date: Thu, 22 Nov 2018 05:16:37 -0800

adventureloop commented on this pull request.

We use term MPS in DPLPMTUD, we have found that keeping the various packet size
values straight is quite hard. It is easier to reason about the sizes when
you seperate away the path size (PMTU), the estimate of the path size and the
size the transport can send (MPS).

I would not object to using 'maximum packet size' rather than an acronym.

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

---

From: Tom Jones <[email-masked]>
Date: Thu, 22 Nov 2018 05:24:18 -0800

41c0a6d  Update based on review from @MikeBishop

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2036/files/0c88ff5d4e8d353f86b2cb767cee9008b8bd6f87..41c0a6d60ad43267efa3e10f5eb48485080a128c

---

From: Tom Jones <[email-masked]>
Date: Thu, 22 Nov 2018 05:25:24 -0800

812e811  Add section reference

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2036/files/41c0a6d60ad43267efa3e10f5eb48485080a128c..812e811f195ee6578e8fe4b93017a64cf54268cd

---

From: Tom Jones <[email-masked]>
Date: Thu, 22 Nov 2018 05:27:35 -0800

e84ed48  Clarify source port is used per connection

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2036/files/812e811f195ee6578e8fe4b93017a64cf54268cd..e84ed484f0e9f852d5b9cbb8c8b8b78dddc59bba

---

From: Tom Jones <[email-masked]>
Date: Thu, 22 Nov 2018 05:32:34 -0800

>  Assuming the minimum IP header size, this results in
> a QUIC MPS of 1232 bytes for IPv6 and 1252 bytes for IPv4. A QUIC
> implementation MAY be more conservative in computing the QUIC MPS to allow for
> unknown tunnel overheads or IP header options/extensions.

>From above the QUIC minimum packet size would be 1252 or 1232. We avoided a number here to be consistent with the 'MAY be more conservative'

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

---

From: Martin Thomson <[email-masked]>
Date: Thu, 22 Nov 2018 14:24:06 -0800

The reason I point this out is that the minimum isn't a minimum, it's just the minimum for an Initial packet.  The minimum packet size is something like 21 bytes absent context.  I think that the minimum in this context is probably 1200, which is the lower limit on what servers accept, but then clients don't enforce any such limit.  And of course, probing at 1200 on IPv6 is pointless.

In other words, you do need to be a little more precise.

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

---

From: Tom Jones <[email-masked]>
Date: Mon, 26 Nov 2018 02:19:15 -0800

b1bde22  Quote a number for BASE_PMTU

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

---

From: Tom Jones <[email-masked]>
Date: Mon, 26 Nov 2018 02:24:33 -0800

bd393e1  Expand MPS to maximum packet size

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

---

From: Mike Bishop <[email-masked]>
Date: Mon, 26 Nov 2018 12:11:47 -0800

You need to trim trailing whitespace for the doc to build.

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

---

From: Martin Thomson <[email-masked]>
Date: Mon, 26 Nov 2018 15:28:04 -0800

@martinthomson pushed 1 commit.

64afb14  spaces

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2036/files/bd393e14663b15df20d2c6e4d309d76c60679590..64afb144387e977e7518bbcf88e05398bfb7f0d6

---

From: Martin Thomson <[email-masked]>
Date: Mon, 26 Nov 2018 16:58:02 -0800

b17f745  moar space

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2036/files/64afb144387e977e7518bbcf88e05398bfb7f0d6..b17f7456ee5e1409c4157f6446431e4a3ba044db

---

From: Martin Thomson <[email-masked]>
Date: Mon, 26 Nov 2018 17:23:18 -0800

I think that this is in good shape, but I wanted to suggest a few tweaks: https://github.com/uoaerg/base-drafts/pull/1

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

---

From: martinduke <[email-masked]>
Date: Mon, 26 Nov 2018 19:55:49 -0800

martinduke commented on this pull request.

Thank you for updating the reference to PLPMTUD.

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

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

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

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

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

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

---

From: martinduke <[email-masked]>
Date: Mon, 26 Nov 2018 20:02:11 -0800

It appears that the rest of this section simply repeats section 6.4 of the DPLPMTUD draft, which seems unnecessary, except the bit about ICMP processing.

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

---

From: Tom Jones <[email-masked]>
Date: Tue, 27 Nov 2018 10:31:28 +0000 (UTC)

@adventureloop pushed 2 commits.

d69f796  Reflow, fixup
02cd828  Merge pull request #1 from quicwg/uoaerg-uoa/dplpmtu

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2036/files/b17f7456ee5e1409c4157f6446431e4a3ba044db..02cd8284170120996c3eb7517c30999eda525cce

---

From: ianswett <[email-masked]>
Date: Tue, 27 Nov 2018 16:39:53 +0000 (UTC)

ianswett approved this pull request.

Nice PR, some small suggestions.

> @@ -2998,17 +2998,15 @@ The QUIC packet size includes the QUIC header and integrity check, but not the
 UDP or IP header.
 
 Clients MUST ensure that the first Initial packet they send is sent in a UDP

nit: how about:
"Clients MUST ensure they send the first Initial packet in a UDP datagram that is at least 1200 bytes."

> @@ -3023,83 +3021,108 @@ The server MUST also limit the number of bytes it sends before validating the
 address of the client, see {{address-validation}}.

-## Path Maximum Transmission Unit
+## Path Maximum Transmission Unit (PMTU)
+
+The PMTU is the maximum size of the entire IP packet including the IP header,
+UDP header, and UDP payload.  The UDP payload includes the QUIC packet header,
+protected payload, and any authentication fields. This can depend upon the

```suggestion
protected payload, and any authentication fields. The PMTU can depend upon the
```

> @@ -3023,83 +3021,108 @@ The server MUST also limit the number of bytes it sends before validating the
 address of the client, see {{address-validation}}.

-## Path Maximum Transmission Unit
+## Path Maximum Transmission Unit (PMTU)
+
+The PMTU is the maximum size of the entire IP packet including the IP header,
+UDP header, and UDP payload.  The UDP payload includes the QUIC packet header,
+protected payload, and any authentication fields. This can depend upon the
+current path characteristics.  Therefore, the current largest UDP payload an
+implementation will send is referred to as QUIC maximum packet size.

```suggestion
implementation will send is referred to as the QUIC maximum packet size.
```

 If a QUIC endpoint determines that the PMTU between any pair of local and remote
-IP addresses has fallen below 1280 bytes, it MUST immediately cease sending QUIC
-packets on the affected path.  This could result in termination of the
-connection if an alternative path cannot be found.
+IP addresses has fallen below the size needed to support the smallest allowed
+maximum packet size, it MUST immediately cease sending QUIC packets on the
+affected path.  This could result in termination of the connection if an

This recommendation results in a timeout in cases where it may be possible to immediately close the connection if no other paths are available. I think it'd be preferable to close the connection, or say it MAY close the connection?

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

---

From: Martin Thomson <[email-masked]>
Date: Tue, 27 Nov 2018 16:41:03 -0800

Merged #2036 into master.

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

---

From: Martin Thomson <[email-masked]>
Date: Tue, 27 Nov 2018 16:41:53 -0800

Thanks for this!  It's a large change, but well-written and a big improvement.

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