Subject: MAX_PACKET_SIZE frame

From: "Lubashev, Igor" <[email-masked]>
Date: Wed, 20 Mar 2019 00:35:48 +0000

This is likely a v2 feature, but I want to mention this now in case some people may be interested in this as a v1 extension (or even think that it clears our new high bar for the transport draft).

There are several ongoing efforts in IETF to have network deliver PMTU information to the intended destination, in addition to sending the traditional ICMP PTB message to the sender from an on-path device.

For example, two drafts in 6man use IPv6 HBH headers for this purpose: https://tools.ietf.org/html/draft-hinden-6man-mtu-option attempts to collect PMTU information using small packets, while https://tools.ietf.org/html/draft-leddy-6man-truncate attempts to do the same using large packets.

In all cases, if an endpoint learns the PMTU from the sender to itself, there is still a problem of passing that information back to the sender.  We know that ICMP PTB has only limited chances of getting back to the sender, even if sent directly by the receiver.  However, a QUIC packet with MAX_PACKET_SIZE frame that updates the "max_packet_size" transport parameter solves the problem.  Hence the proposed new frame.

  *   Igor

P.S.
  It would also make sense to allow mss update for a TCP connection after connection establishment to serve the same purpose.  That'd be a matter for tcpm WG.

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 20 Mar 2019 00:27:20 -0400

The relationship between packet size and datagram size isn't as fixed as this would assume.  I suspect that you want to have an MTU frame instead.

On Wed, Mar 20, 2019, at 11:36, Lubashev, Igor wrote:
>  
> This is likely a v2 feature, but I want to mention this now in case 
> some people may be interested in this as a v1 extension (or even think 
> that it clears our new high bar for the transport draft).
> 
> 
> There are several ongoing efforts in IETF to have network deliver PMTU 
> information to the intended destination, in addition to sending the 
> traditional ICMP PTB message to the sender from an on-path device.
> 
> 
> For example, two drafts in 6man use IPv6 HBH headers for this purpose: 
> https://tools.ietf.org/html/draft-hinden-6man-mtu-option attempts to 
> collect PMTU information using small packets, while 
> https://tools.ietf.org/html/draft-leddy-6man-truncate attempts to do 
> the same using large packets.
> 
> 
> In all cases, if an endpoint learns the PMTU from the sender to itself, 
> there is still a problem of passing that information back to the 
> sender. We know that ICMP PTB has only limited chances of getting back 
> to the sender, even if sent directly by the receiver. However, a QUIC 
> packet with MAX_PACKET_SIZE frame that updates the “max_packet_size” 
> transport parameter solves the problem. Hence the proposed new frame.
> 
> 
>  * Igor
> 
> P.S.
> 
>  It would also make sense to allow mss update for a TCP connection 
> after connection establishment to serve the same purpose. That’d be a 
> matter for tcpm WG.
>

---

From: Christian Huitema <[email-masked]>
Date: Tue, 19 Mar 2019 21:45:15 -0700

Martin and I (and a few others) had a discussion of the IPv6 MTU
discovery by truncation before. If we want to use something like that in
QUIC, we need more than PMTU option. We probably need to define MTU
probes packets, with a specific header indicating that this is a probe
and it might be truncated, and a content that allows the receiver to
verify that the truncated packet was actually sent by the peer.
Something like a verifiable content encrypted in CBC mode, so the
receiver can check that bytes up to length=L were correctly received.
Then, we would of course have a reporting frame, stating that "at least
L bytes of the probe were received" -- preferably in a verifiable
fashion, to avoid shenanigans.

-- Christian Huitema

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 20 Mar 2019 13:58:11 +0900

> receiver can check that bytes up to length=L were correctly received.

I am not sure if we need something complicated as that, considering
that only the preceding part of the datagram needs to be
authenticated. Sending a long header packet (that authenticates) along
with some padding would be sufficient.

As an example, a sender could possibly send a huge UDP datagram that
consists of an 1-RTT long header packet (that uses the same traffic
keys as 1-RTT short header packets) and some junk data (that acts as
padding) at the end. We can (ab)use the 0-RTT packet type for the
purpose once the handshake is complete.

The receiver would process the packet as normally, and then send back
a MTU frame.

-- 
Kazuho Oku

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 20 Mar 2019 01:11:28 -0400

> with some padding would be sufficient.

It's probably almost enough, but it can be gamed.  Better to use a long PRNG (an XOF is ideal here) that is seeded from a secret on the endpoint share.  Otherwise, middleboxes can play games, like adding bytes, or removing the wrong ones.  Not sure what the threat model is, but the cost of generating a bitstream from an XOF is negligible.

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 20 Mar 2019 07:54:33 +0000

> It's probably almost enough, but it can be gamed.  Better to use a long PRNG (an XOF is ideal here) that is seeded from a secret on the endpoint share.  Otherwise, middleboxes can play games, like…

I thought this was punted to v2 of the spec.

Isn't it better to explore how DPLPMTUD works?  What sould be the 
advantage of adding extra machinery to QUIC for this?

The various proposals to add network-layer support are to be discussed 
in 6MAN this coming IETF. Isn't it better to explore how DPLPMTUD 
works?  What sould be the advantage of adding extra machinery to QUIC 
for this?

Gorry

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 20 Mar 2019 04:23:25 -0400

> I thought this was punted to v2 of the spec.

Igor suggested that it would be better suited to v2.  And I agree.  If someone disagrees, they can open an issue and ask the chairs' opinions.

---

From: "Lubashev, Igor" <[email-masked]>
Date: Wed, 20 Mar 2019 15:13:18 +0000

Sounds good to me.

Incidentally, there is another use for MAX_PACKET_SIZE, independent of the support for the future network layer features.

QUIC supports connection migration.  For an anycast server deployment, such connection migration may cause the new path to reach a different anycast node.  That would require tunneling the packets from the new anycast node to the original anycast node.  I would expect that significantly fewer than 1% of connections will migrate to another anycast node during their lifetime.  The server deployment would either pre-emptively set pack_packet_size transport parameter low enough to accommodate the possible tunneling overhead (something that would needlessly reduce the efficiency of >99% of connections) or send MAX_PACKET_SIZE frame after the migration only to those connections that need it.

> -----Original Message-----
> From: Martin Thomson <[email-masked]>
> Sent: Wednesday, March 20, 2019 4:23 AM
> To: [email-masked]
> Subject: Re: MAX_PACKET_SIZE frame
> 
> Igor suggested that it would be better suited to v2.  And I agree.  If someone
> disagrees, they can open an issue and ask the chairs' opinions.