Subject: [quicwg/base-drafts] Do we need to define a maximum packet size? (#383)

From: Marten Seemann <[email-masked]>
Date: Thu, 09 Mar 2017 17:21:31 -0800

In the error codes there's a QUIC_PACKET_TOO_LARGE error, but there's no maximum packet size specified anywhere in the document.

Does it make sense to define a maximum packet size or must a QUIC implementation be capable of handling packets with the maximum UDP packet size? Google QUIC currently uses 1452 as the maximum packet size (= Ethernet MTU - minimum UDP header size).

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

---

From: ianswett <[email-masked]>
Date: Thu, 09 Mar 2017 17:30:14 -0800

I would propose we remove this error code, unless there's some compelling reason for it to exist.

GQUIC doesn't even use it anymore in practice, though there is some possibility of packets that are too large being dropped in the current implementation.  

-- 
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/383#issuecomment-285545990

---

From: Martin Thomson <[email-masked]>
Date: Thu, 09 Mar 2017 17:35:27 -0800

Dropping a packet that is too large isn't ideal, since that doesn't prevent more packets of that size arriving in future.  Do we need a mechanism?  Do we need to offer any guidance?

-- 
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/383#issuecomment-285546841

---

From: Martin Thomson <[email-masked]>
Date: Thu, 09 Mar 2017 17:39:27 -0800

A potential mechanism: TLS has a [max_fragment_length extension](https://tools.ietf.org/html/rfc6066#section-4).  This allows endpoints to set a limit on record size, which is especially helpful when the endpoint is memory-constrained.  Obviously, a TCP-based protocol offers more opportunity to have large packets, but big UDP packets aren't impossible.

-- 
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/383#issuecomment-285547530

---

From: Igor Lubashev <[email-masked]>
Date: Thu, 09 Mar 2017 19:22:05 -0800

1452 is certainly too small. QUIC should allow at least PMTU-sized UDP packets (unless negotiated lower). MTU of localhost in quite large. Jumbo packets exist.

-- 
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/383#issuecomment-285562614

---

From: Marten Seemann <[email-masked]>
Date: Thu, 09 Mar 2017 23:01:22 -0800

I'd like to make the argument that if we don't define a maximum packet size here, implementations should be allowed to choose one and drop larger packets.

I have very little experience with PMTUD, but wouldn't consistently dropping these packets look like one element on the path doesn't suppport the higher MTU and cause the peer to reduce the packet size?

Setting a maximum packet size is essentially a DoS defense for an implementation. During the handshake, undecrytable packets have to be queued (because reordering can happen). In quic-go, we're queuing up to 10 packets before sending a Public Reset, which is a reasonably small memory commitment of about 15 kB. Things might look different if these were maximum size UDP packets though.

-- 
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/383#issuecomment-285593806

---

From: Aron-Schats <[email-masked]>
Date: Fri, 10 Mar 2017 06:29:27 -0800

Related: pull request #384 proposes that handshake be completed within 64 KB of stream 1 data.

-- 
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/383#issuecomment-285682438

---

From: ianswett <[email-masked]>
Date: Fri, 10 Mar 2017 06:53:54 -0800

@martinthomson Dropping packets that are too large doesn't provide much feedback, but that's a failure mode QUIC, at least in Chrome, has to deal with gracefully.  It's much more likely the path drops the packet before it arrives at the server, possibly sending an ICMP packet in the process.

For a while, GQUIC would read packets up to 2000 bytes, but send back an error if the packet was larger than 1460 or something.  This path was almost never hit, but created unnecessary code complexity.

So I'd support no max packet size, with dropping being the way to deal with overly large ones, but possibly we want to require all endpoints support 1500 byte packets as a minimum?

-- 
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/383#issuecomment-285688621

---

From: Aron-Schats <[email-masked]>
Date: Fri, 10 Mar 2017 07:09:47 -0800

> ...but possibly we want to require all endpoints support 1500 byte packets as a minimum?

@ianswett, why?

-- 
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/383#issuecomment-285692876

---

From: ianswett <[email-masked]>
Date: Fri, 10 Mar 2017 08:45:55 -0800

I was thinking that a peer would want to know what the max MTU it should try is if we're doing PathMTU, and that most connections would want to use a size a bit larger than 1280.  

But possibly this is something that could be sent in the handshake if we thought it was useful, instead of having a mandated size?

-- 
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/383#issuecomment-285720077

---

From: Aron-Schats <[email-masked]>
Date: Fri, 10 Mar 2017 13:32:44 -0800

Why mandate a minimum size at all?  I think it should be up to the server.  If the server is waiting to accept packets carrying just 10 bytes (for example) of stream data payload, so be it.  Certainly it is not a good idea for a web server on the Internet as it would take hundreds of packets to complete a handshake, but who knows how someone would want to use 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/383#issuecomment-285790468

---

From: janaiyengar <[email-masked]>
Date: Fri, 10 Mar 2017 15:36:02 -0800

@Aron-Schats: the minimum size is required to avoid amplification attacks (see Packetization and Reliability section in the transport draft.) 

I think removing the error code is fine. Anything that an endpoint sends as an untested packet size mid-connection will naturally be a part of PMTUD, in which case, the endpoint will also be prepared to deal with it getting dropped. I would expect detecting server support of an untested packet size to be part of PMTUD.

-- 
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/383#issuecomment-285814632

---

From: Martin Thomson <[email-masked]>
Date: Sun, 12 Mar 2017 17:29:56 -0700

I agree with the view that this looks a lot like PMTUD, providing that the endpoint is consistent in how it drops larger packets.

Is there any value in signaling a maximum if you are operating a constrained implementation?

-- 
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/383#issuecomment-285990851

---

From: Igor Lubashev <[email-masked]>
Date: Sun, 12 Mar 2017 23:25:02 -0700

If you are a constrained implementation or you know that you are behind a path with PMTU smaller than usual, it is better to let the peer know rather than have the peer waste a round trip (in the best case) to discover this for itself.

TCP negotiates MSS.

-- 
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/383#issuecomment-286024642

---

From: ianswett <[email-masked]>
Date: Mon, 13 Mar 2017 06:13:06 -0700

It may be nice to signal MSS, but this could only be the endpoint value, unless one of the peers had particularly good knowledge of the path.  So I'd suggest a handshake negotiated value, to the min of the two peers, since it's assume the max endpoint size is the same for sending and receiving.

-- 
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/383#issuecomment-286102911