How the QUIC protocol finds the maximum MTU for a session ?

[Romain Jacotin]

QUIC requires to not have IP fragmentation. By looking at the source code, it seems that QUIC assumes a maximum of 1392:

• Ether=14
• IPv4=20
• UDP=8
• QUIC=1350
  

Is it a static configuration, or do you have some "tricks" during the "no encryption" initialization phase to change this value (increment or decrement) ?

https://chromium.googlesource.com/chromium/src/net/+/master/quic/quic_protocol.h

1. // Default and initial maximum size in bytes of a QUIC packet.
2. const QuicByteCount kDefaultMaxPacketSize = 1350;
3. // Default initial maximum size in bytes of a QUIC packet for servers.
4. const QuicByteCount kDefaultServerMaxPacketSize = 1000;
5. // The maximum packet size of any QUIC packet, based on ethernet's max size,
6. // minus the IP and UDP headers. IPv6 has a 40 byte header, UPD adds an
7. // additional 8 bytes. This is a total overhead of 48 bytes. Ethernet's
8. // max packet size is 1500 bytes, 1500 - 48 = 1452

https://chromium.googlesource.com/chromium/src/net/+/master/quic/quic_packet_creator.cc

1. QuicPacketCreator::QuicPacketCreator(QuicConnectionId connection_id,
2. QuicFramer* framer,
3. QuicRandom* random_generator)
4. ...
5. {
   
6. SetMaxPacketLength(kDefaultMaxPacketSize);
7. }

Kind regards,

Romain

[Ian Swett]

Currently it's a static value chosen client side, which was based on some empirical testing.  All handshake packets must be padded to the full size in both directions, so if the MTU is too large, the handshake fails and Chrome falls back just like it would if UDP was blocked entirely.

We choose a slightly smaller QUIC payload size for IPv6 due to the extra overhead.

--
You received this message because you are subscribed to the Google Groups "QUIC Prototype Protocol Discussion group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to proto-quic+...@chromium.org.
To post to this group, send email to proto...@chromium.org.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.

[Jim Roskind]

The viability of the link with your calculated 1392 MTU in both directions is indeed tested during the HELLO exchanges, as those initial packets are fully padded to that size, independent of actual payload quantity.  Although this is far from a fool-proof method of validating MTU (and MTU can change dynamically with routing etc.), it empirically works well.

The value seen in the code was selected after a lot of experimentation with real-world traffic and path patterns.  It represented a compromise between reachability (smaller packets sizes get through in more scenarios), and efficiency (larger packets waste less bandwidth on overhead for a given payload.  

It is also good to keep in mind that QUIC was designed to fall-back to TCP when a connection cannot handle the traffic (especially the HELLO negotiations).  This is, for instance, a notably problem if a user has a firewall blocking UDP traffic on the ports that QUIC utilizes (it is not a "frequent" problem, but it has to be dealt with).  This need to fallback then works to cover the case where MTU problems preclude, or degrade (demolish?) a connection.

Jim

[Romain Jacotin]

Thank you both for taking time to answer. :)

Romain

[Romain Jacotin]

Optimization: can we consider having 1350 bytes for QUIC packet size for IPv6 and 1370 bytes (+20) for IPv4 ?

Using QUIC as server-to-server protocol also, i can decide having a bigger QUIC packet size in IPv4 like 1472 (by tuning): if so, is it mandatory to also add full padding for the initialization HELLO packet exchange ?

[Ryan Hamilton]

On Sat, May 23, 2015 at 1:24 AM, Romain Jacotin <romain....@orange.fr> wrote:

Optimization: can we consider having 1350 bytes for QUIC packet size for IPv6 and 1370 bytes (+20) for IPv4 ?

​We do exactly this. Check out quic_client_session.cc:

  if (socket && socket->GetLocalAddress(&address) == OK &&

      address.GetFamily() == ADDRESS_FAMILY_IPV6) {

    connection->set_max_packet_length(

        connection->max_packet_length() - kAdditionalOverheadForIPv6);

  }

​

Using QUIC as server-to-server protocol also, i can decide having a bigger QUIC packet size in IPv4 like 1472 (by tuning): if so, is it mandatory to also add full padding for the initialization HELLO packet exchange ?

​Yes, the server uses the size of the CHLO packet ​to specify the maximum packet size used going forward. Of course, some other scheme could be used to detect a different MTU, but no such mechanism currently exists. 

Cheers,

Ryan

[Romain Jacotin]

Thank you Ryan,

• If IPv4 then QUIC max packet size = 1350
  
• If IPv6 then QUIC max packet size = 1350-20 = 1330
  
• And all initial QUIC HELLO packet MUST be padded to QUIC max packet size.
  

Romain (working on QUIC implementation in full Golang)

[Ryan Hamilton]

On Sun, May 24, 2015 at 5:53 AM, Romain Jacotin <romain....@orange.fr> wrote:

Thank you Ryan,

• If IPv4 then QUIC packet size = 1350
  

• If IPv6 then QUIC max packet size = 1350-20 = 1330
  

​Yes, this is what Chrome uses, though different clients could use different values if they wished. (And Chrome has used different values before we arrived at 1350).​

• And all initial QUIC HELLO packet MUST be padded to QUIC max packet size.

​Indeed.​

 

Romain (working on QUIC implementation in full Golang)

​Sounds great!​

[Rob]

I have a packet capture from client using Chrome to Google's server using QUIC.  The firewall in between has the MTU set at 1472.  I am confused as to why I have heavy IP fragmentation when using QUIC though.  The rest of my network flows don't exhibit this degree of IP fragmentation.  
I'm happy to share a pcap (it's 100MB in size).  

[thierry bastardie]

Hi , is there a way to get more than 1350 bytes in QUIC payload in order to fit with future ipv6 network that could offer more than 1500 bytes inside their own networks including access and content caches. Not always time, but in this case, with ipv6 PMTUD , end users could establish end-to-end sessions at more than 1500 bytes.

[Fan Yang]

Hi,

  QUIC has the MTU discovery mechanism (https://cs.chromium.org/chromium/src/net/third_party/quiche/src/quic/core/quic_mtu_discovery.h). 

  Currently, we are actively experimenting with MTU discovery of the direction server -> client (since server is mostly the data sender), and I think it is trivial to enable MTU discovery in both directions.

  

  Hope that helps!

  Fan

--
You received this message because you are subscribed to the Google Groups "QUIC Prototype Protocol Discussion group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to proto-quic+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/proto-quic/b4c149d9-a4c5-42f0-8700-7209126f2eb9o%40chromium.org.