Subject: Space for Packet Metadata

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Wed, 28 Feb 2018 00:11:43 -0800

Would it make sense to reserve space for additional metadata by reducing
the required initial packet size to, say 1000 octets in order to allow for
a smaller PMTU than the actual PMTU?

This could simplify tunnelling and monitoring, and also other cases where
multiple servers cooperate on handling a single connection.

Kind Regards,
Mikkel Fahnøe Jørgensen

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 28 Feb 2018 06:07:18 -0800

> multiple servers cooperate on handling a single connection.

How do you imagine those servers would use this space?

-Ekr

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Wed, 28 Feb 2018 06:34:18 -0800

One example is forming a consensus across servers handling connections from
multiple clients concurrently. A current leader receives the packet and
either just signs it, or verifies the content first, then forwards the
packet to n - 1 other servers in different datacenters (depending on
protocol). Once enough signatures have been collected, the packet is
accepted and processed, adding an ordering across all connections. If a
server is compromised, it can’t do something with the packet the other
server haven’t already authorised. In some protocols each additional server
would add to the previous signature thus requiring quite a few signatures
to ensure consensus. It is of great value to have these signatures in a
single packet because it provides atomic read guarantees. This can easily
consume 80 or more bytes.

Obviously there is a lot more to it than that, and it can be done after
unwrapping QUIC and via secure point to point communication, but that would
be less efficient and you might have difficulty proving the content
originated from a given client without even more signatures, and the client
might have to be involved in the protocol.

It only works, it you keep enough servers safe, or course:

https://www.vox.com/world/2017/6/13/15791744/russia-election-39-states-hack-putin-trump-sessions

This is just one example, but any time a backend needs to coordinate, extra
space might be useful. Another example could be a virtual routing token
added at the end of the packet.

---

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 28 Feb 2018 14:58:11 +0000

Hi,

On 2018-2-28, at 9:11, Mikkel Fahnøe Jørgensen <[email-masked]> wrote:
> 
> Would it make sense to reserve space for additional metadata by reducing the required initial packet size to, say 1000 octets in order to allow for a smaller PMTU than the actual PMTU?
> 
> This could simplify tunnelling and monitoring, and also other cases where multiple servers cooperate on handling a single connection.

any such servers can already "reserve" such space by not forwarding packets that exceed whatever limit they want to enforce - this is how PMTUD works.

Lars

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Wed, 28 Feb 2018 07:03:41 -0800

Yes, but can it go below 1200? It seems the handshake aims to squeeze up
near the minimum guaranteed (required) PMTU and QUIC implementations would
probably not expect to maintain a connection that drops below PMTU 1200.

I’m not saying it can’t work, rather I'm asking because I don’t think so.

On 28 February 2018 at 15.58.39, Eggert, Lars ([email-masked]) wrote:

any such servers can already "reserve" such space by not forwarding packets
that exceed whatever limit they want to enforce - this is how PMTUD works.

---

From: Christian Huitema <[email-masked]>
Date: Wed, 28 Feb 2018 07:19:09 -0800

On 2/28/2018 7:03 AM, Mikkel Fahnøe Jørgensen wrote:
> Yes, but can it go below 1200? It seems the handshake aims to squeeze
> up near the minimum guaranteed (required) PMTU and QUIC
> implementations would probably not expect to maintain a connection
> that drops below PMTU 1200.
>
> On 28 February 2018 at 15.58.39, Eggert, Lars ([email-masked]
> <mailto:[email-masked]>) wrote:
>
>> any such servers can already "reserve" such space by not forwarding
>> packets that exceed whatever limit they want to enforce - this is how
>> PMTUD works. 

What Lars said. If networks want to play game with extra forwarding
overhead, they have to ensure that they can tunnel a min MTU packet,
i.e. 1280 bytes. Which is not a problem since the local MTU is generally
1536 bytes, and there is no practical reason to have more than 200 bytes
of overhead.

-- Christian Huitema

---

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 28 Feb 2018 15:12:29 +0000

On 2018-2-28, at 16:03, Mikkel Fahnøe Jørgensen <[email-masked]> wrote:
> Yes, but can it go below 1200? It seems the handshake aims to squeeze up near the minimum guaranteed (required) PMTU and QUIC implementations would probably not expect to maintain a connection that drops below PMTU 1200.

The minimum IPv4 MTU is 576, so I'd expect QUIC stacks to probe as least that low.

Lars

---

From: Nick Banks <[email-masked]>
Date: Wed, 28 Feb 2018 15:30:23 +0000

According to spec, QUIC requires at least 1280 (from 9.4):

"QUIC depends on the network path supporting a MTU of at least 1280 octets. This is the IPv6 minimum MTU and therefore also supported by most modern IPv4 networks. An endpoint MUST NOT reduce its MTU below this number, even if it receives signals that indicate a smaller limit might exist.'

- Nick

-----Original Message-----
From: QUIC <[email-masked]> On Behalf Of Eggert, Lars
Sent: Wednesday, February 28, 2018 7:12 AM
To: Mikkel Fahnøe Jørgensen <[email-masked]>
Cc: IETF QUIC WG <[email-masked]>
Subject: Re: Space for Packet Metadata

Lars

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 28 Feb 2018 16:55:02 +0100

> On Feb 28, 2018, at 4:30 PM, Nick Banks <[email-masked]> wrote:
> 
When discussing safe MTU values for WebRTC, 1280 for IPv6 was acceptable, but not for IPv4. After a discussion,
the suggested value for IPv4 was 1200. See
https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-5

Not sure what changed in between...

Best regards
Michael

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Wed, 28 Feb 2018 08:04:35 -0800

https://blogs.cisco.com/enterprise/ipv6-mtu-gotchas-and-other-icmp-issues

IPV6 UDP overhead is 48 bytes
https://en.wikipedia.org/wiki/User_Datagram_Protocol

Minimum expected PMTU is 1280 bytes (and required by QUIC)
Local MTU expected 1536 bytes

1536 - 48 = 1488
1488 - 1280 = 208 bytes

So there is already 208 bytes reserved for tunnelling etc. Which is fine.
Exactly what I was asking for.

On 28 February 2018 at 16.55.05, Michael Tuexen (
[email-masked]) wrote:

> "QUIC depends on the network path supporting a MTU of at least 1280
octets. This is the IPv6 minimum MTU and therefore also supported by most
modern IPv4 networks. An endpoint MUST NOT reduce its MTU below this
number, even if it receives signals that indicate a smaller limit might
exist.'
When discussing safe MTU values for WebRTC, 1280 for IPv6 was acceptable,
but not for IPv4. After a discussion,
the suggested value for IPv4 was 1200. See
https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-5

Best regards
Michael

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 28 Feb 2018 16:06:49 +0000

For IPv6 that may be fine.

The QUIC transport paper (*) Section 7.1 speaks of "Packet Size 
Consideration"- as far as I know this is just UDP traffic from google 
Chrome clients to google servers. They showed 3% unreachable for 1200 B 
payloads. Other networks could well be different.

We are in the midst of a large measurement campaign related to our work 
in TSVWG on path MTU discovery. I would expect a wide variety of Path 
MTUs - even though the current majority of paths will support 1280 
bytes, many IPv4 paths do not - there are also many paths that support 
much more.

Gorry

* 
http://delivery.acm.org/10.1145/3100000/3098842/p183-Langley.pdf?ip=212.159.18.54&id=3098842&acc=OA&key=4D4702B0C3E38B35%2E4D4702B0C3E38B35%2E4D4702B0C3E38B35%2E5945DC2EABF3343C&__acm__=1519833743_fa365ff0c9cc6c6e266add2dba8f385f

On 28/02/2018, 15:30, Nick Banks wrote:
> From: QUIC<[email-masked]>  On Behalf Of Eggert, Lars
> To: Mikkel Fahnøe Jørgensen<[email-masked]>
> Cc: IETF QUIC WG<[email-masked]>
> On 2018-2-28, at 16:03, Mikkel Fahnøe Jørgensen<[email-masked]>  wrote: