Subject: [quicwg/base-drafts] Note that initial packets coalesced with other packets to make a 1200 byte UDP datagram could be split up by the network (#3317)

From: Eric Kinnear <[email-masked]>
Date: Fri, 03 Jan 2020 09:17:45 -0800

While considering https://github.com/quicwg/base-drafts/pull/2925#discussion_r356125209, @MikeBishop suggested that we might want to add some minor text around the discussion of coalescing initial packets to set expectations that the network could split up coalesced packets into separate datagrams which may no longer be 1200+ bytes.

For some history:
#1548 clarified that datagrams are padded to 1200 bytes, not necessarily the initial packets, #2519 added the requirement that not just initial-only datagrams are padded,  #2522 made it such that there are no exceptions to the padding requirement for datagrams containing initial packets.

The current state of things is that: 
- All datagrams containing an initial MUST be 1200+ bytes
- Other packets could be coalesced into the same datagram to reduce waste on the wire
- This limit MAY be enforced as a protocol violation

The current text is:
```
Clients MUST ensure that UDP datagrams containing Initial packets have UDP
payloads of at least 1200 bytes, adding padding to packets in the datagram as
necessary. Sending padded datagrams ensures that the server is not overly
constrained by the amplification restriction.
```

And 
```
A client MUST expand the payload of all UDP datagrams carrying Initial packets
to at least 1200 bytes, by adding PADDING frames to the Initial packet or by
coalescing the Initial packet (see {{packet-coalesce}}). Sending a UDP datagram
of this size ensures that the network path from the client to the server
supports a reasonable Maximum Transmission Unit (MTU).  Padding datagrams also
helps reduce the amplitude of amplification attacks caused by server responses
toward an unverified client address; see {{address-validation}}.

Datagrams containing Initial packets MAY exceed 1200 bytes if the client
believes that the Path Maximum Transmission Unit (PMTU) supports the size that
it chooses.

A server MAY send a CONNECTION_CLOSE frame with error code PROTOCOL_VIOLATION in
response to an Initial packet it receives from a client if the UDP datagram is
smaller than 1200 bytes. It MUST NOT send any other frame type in response, or
otherwise behave as if any part of the offending packet was processed as valid.
```

This generally seems reasonable, however we have some choices to make: 
Option 1, keep the current behavior: 
Consider the network changing this a failure, as we no longer establish >1200 byte connectivity for packets. Keep the enforcement, add an editorial note that the network could mess with these packets and cause the establishment to fail. Let these connections go.

Option 2, prevent this from failing the handshake: 
Remove the enforcement or add a note clarifying when you MAY *not* want to error out. This seems tricky as there's no way to tell that the network made the change vs. the remote endpoint. Rethink our assumptions about having >1200 byte connectivity for datagrams everywhere.

I would lean rather strongly towards Option 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/issues/3317

---

From: ekr <[email-masked]>
Date: Fri, 03 Jan 2020 10:55:10 -0800

I agree. Let's stick with Option 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/issues/3317#issuecomment-570664103

---

From: ianswett <[email-masked]>
Date: Fri, 03 Jan 2020 10:57:49 -0800

Let's stick with Option 1 and add a note to the manageability doc about how splitting coalesced packets could cause the handshake to fail, so don't do it.

-- 
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/issues/3317#issuecomment-570664837

---

From: Jana Iyengar <[email-masked]>
Date: Sat, 04 Jan 2020 17:03:23 -0800

Let's not do anything here. We'll get deployment experience with v1, and we might want to revisit this question afterwards, but we have no reason to believe that this is an important problem to solve in practice.

-- 
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/issues/3317#issuecomment-570834155

---

From: Christian Huitema <[email-masked]>
Date: Sun, 05 Jan 2020 11:34:13 -0800

What @ianswett said. It will be almost impossible for any operator to ship boxes that cause connections to fail. Hence option 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/issues/3317#issuecomment-570940376

---

From: Eric Kinnear <[email-masked]>
Date: Mon, 13 Jan 2020 13:21:08 -0800

I also think option 1 is much preferred.
Will make a PR with a minor editorial note to indicate 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/issues/3317#issuecomment-573876578

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 16 Jan 2020 20:59:01 -0800

Keeping open to get the editorial task done; previous decisions NOT reopened.

-- 
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/issues/3317#issuecomment-575465204