Subject: [quicwg/base-drafts] Minimum MTU (#139)

From: martinduke <[email-masked]>
Date: Tue, 10 Jan 2017 15:45:13 -0800

Is there a minimum MTU we want QUIC to enforce? If so, how big? If an endpoint discovers this is not achievable, what then? Do they have to fail over to TCP, or do we just let the (IPv4) network fragment packets?

-- 
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/139

---

From: ianswett <[email-masked]>
Date: Tue, 10 Jan 2017 16:23:53 -0800

I believe there are three approaches I can think of.
  1) Define a fixed reasonable value, such as 1024 bytes.  
  2) Define the minimum value in terms of what can fit the client hello message, since requiring multi-packet CHLOs requires storing state, and that eliminates stateless rejects.
  3) Both of the above.

At the moment, my gut is that we want #3, and when they are not achievable, we fall back to TCP.  Given IPv6 is the future(admittedly, not completely here yet), designing anything with IPv4 only in mind seems unwise.

-- 
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/139#issuecomment-271740921

---

From: Martin Thomson <[email-masked]>
Date: Tue, 10 Jan 2017 17:05:47 -0800

As a practical matter, a lot of paths will support IPv6, which mandates a 1280 octet minimum MTU and so that flows.  We could just pick that value.  Which has the benefit(?) of providing more incentive to use IPv6.

FWIW, the TLS ClientHello rarely exceeds 256 octets for an inchoate message.  We have this bug for which the workaround means padding to 512 if the size hits 256, so we have good experience with how often that limit is hit.

I believe that a 0-RTT ClientHello *will* often exceed 256 octets though because tickets can get pretty large.  I can't imagine exceeding 512 with the configuration we have today, even with 0-RTT. 

That could very well change if we have to move to PQ crypto, which sometimes have absurdly large public keys.  I don't see us using anything that would push the ClientHello over 1024 octets though, we'd probably reject a PQ algorithm that forced us to do that, unless we were getting a little desperate.  On that basis, 1024 would seem to be plenty.

-- 
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/139#issuecomment-271747782

---

From: martinduke <[email-masked]>
Date: Wed, 11 Jan 2017 11:54:25 -0800

A related issue is whether we are defining the minimum packet size or the minimum UDP payload. For instance, we could specify a minimum UDP payload of 1232, which would translate to an MTU of 1260 for IPv4 and 1280 for IPv6, assuming no options.

I would most prefer a min MTU of 1280 or so, as it saves us having to have different limits for IPv4 and IPv6. I'm somewhat concerned that there is a lot of legacy network equipment (or tunnels) out there that might have smallish MTUs and an interest in using QUIC.

-- 
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/139#issuecomment-271976064

---

From: hardie <[email-masked]>
Date: Thu, 12 Jan 2017 10:49:11 -0800

Why do we want QUIC to enforce a minimum MTU?  On the v6 side, this issue is sorted; are you concerned that you'll get black hole connections on v4?  If that is the case, won't those effect TCP as well, so that fallback to TCP doesn't help?

-- 
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/139#issuecomment-272247579

---

From: Martin Thomson <[email-masked]>
Date: Thu, 12 Jan 2017 16:50:11 -0800

Having a minimum would help with #136 and #38.

-- 
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/139#issuecomment-272330241

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 25 Jan 2017 18:19:12 -0800

Closed #139.

-- 
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/139#event-937144814

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 25 Jan 2017 18:19:12 -0800

As discussed in Tokyo, resolved as part of #64 / PR #106 

-- 
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/139#issuecomment-275292453