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

[Eric Kinnear <[e-mail]>]

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