Subject: [quicwg/base-drafts] Transport: Can QUIC packets become larger than 64K? (#611)

From: Magnus Westerlund <[email-masked]>
Date: Thu, 08 Jun 2017 01:33:05 -0700

In reviewing the transport-03 protocol I was wondering if there is actual hard upper limit in QUIC packets that can they never can become larger than 64K? So for IPv4 and normal IPv6 that is the limit for IP/UDP/QUIC. If one would have IPv6 Jumbograms (RFC 2675) could you actually make use of them with QUIC? 

So Stream Frame has a 64 K payload limit, but one can include multiple Stream Frames, different streams or depending on answer to #610 maybe the same stream. 

Thus the question is if the documents are either explicitly saying that the upper limit to a QUIC packet is 64K, not mention this at all, or be explicit that there are no actual upper limit. This is for cases where one have an MTU that is this large and thus not trip over the conclusion of  #383 and would not have the signaling limit the packet size as discussed in  #501 

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

---

From: Martin Thomson <[email-masked]>
Date: Thu, 08 Jun 2017 05:57:19 -0700

The maximum packet size PR, #501, should answer this question: that PR places a hard upper bound on the packet size of 65535.  Note that there is an advantage in having a lower limit, in that larger blocks have some negative latency effects, even if you can send and receive them.  Yes, that makes it impossible to send mega-uber-jumbo packets.  If you can make a case for those packets, you should make that case.

-- 
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/611#issuecomment-307094982

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 08 Jun 2017 06:17:32 -0700

Yes, that PR puts that limit in effect. I currently don't have any reason for argue for jumbo IPv6 packet support at the point. The question is if this limit should be made somewhere else also? 

-- 
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/611#issuecomment-307100126

---

From: MikkelFJ <[email-masked]>
Date: Thu, 08 Jun 2017 07:33:19 -0700

The one use case I can see for very large packets is SAN networks like iSCSI where the packet loss and latency is low and data volumes high. Here you might as well use TCP/IP, except that QUIC offers built-in encryption and authentication that might be useful against compromised networks.

In general large packets works against the idea of stream multiplexing.

-- 
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/611#issuecomment-307122123

---

From: Martin Thomson <[email-masked]>
Date: Fri, 09 Jun 2017 00:06:40 -0700

> In general large packets works against the idea of stream multiplexing.

That's not true.  A large packet can contain many things.  What is true is that excessive time spend on sending large chunks of data means that it can be difficult to respond to changes in circumstance quickly.  But as long as the packets don't take too long to send, I don't see a significant problem with larger packets, at least in theory.

-- 
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/611#issuecomment-307313019

---

From: MikkelFJ <[email-masked]>
Date: Fri, 09 Jun 2017 00:11:48 -0700

Well, that is correct - it does not work against multiplexing.

But it does work against stream independence and head of line blocking. Which is a gradual transition from small to large packets and "large" obviously depends on network conditions. Large packets both increases retransmission latency and may force more streams into the same packet due to lack of readily available content. Small packets also have downsides such as not ensuring that at least some frames make it through unharmed at low latency, and decreased bandwidth.

The http/2 vs http/1.1 discussion circles around multiplexed streams over one connection vs independent streams over multiple connections. There is no clear winner.

-- 
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/611#issuecomment-307313930

---

From: Martin Thomson <[email-masked]>
Date: Fri, 09 Jun 2017 06:35:52 -0700

I don't really want to get deep into the weeds on the various trade-offs between longer and shorter transmission units.  The facts in this case support the upper limit we have - it is rare to see support of UDP jumbograms.  I will keep this issue open to discuss that possibility, but I'm parking it because it's a distraction from other issues and unless someone has a strong use cases for going over 64k that involves bilateral agreement to do so, I think we're in good shape as things stand.  If that use case ever appears, we will change the size of the new max_packet_size field, which is easy enough to do.  Currently, I see no good justification.

-- 
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/611#issuecomment-307390255