Subject: Re: #540: "jumbo" frames

From: Amos Jeffries <[email-masked]>
Date: Fri, 11 Jul 2014 01:05:03 +1200

On 25/06/2014 10:20 p.m., David Krauss wrote:
> 
> On 2014–06–25, at 5:35 PM, <[email-masked]> <[email-masked]> wrote:
> 
>> Bad idea IMO.  That would really paint HTTP/2 into a corner.  With no reserved bits left, there would never be a chance to go above 64K frames.  i.e. you could never " back-port bigger frames onto an existing protocol"
> 
> IPv6 packets only go up to 64K, so no network processor is going to get away with coarser granularity for the foreseeable future.
> 

http://staff.psc.edu/mathis/MTU/limits.html :

 IPv6 - The extended length option provides for a 32 bit length field,
supporting packets up to 4294967295 bytes.

Amos

---

From: Nicholas Hurley <[email-masked]>
Date: Thu, 10 Jul 2014 10:32:53 -0700

> supporting packets up to 4294967295 bytes.

With the operative words there being "extended" and "option". So why can't
we do this in an extension, again?
--
Peace,
  -Nick

---

From: Jeff Pinner <[email-masked]>
Date: Thu, 10 Jul 2014 10:37:22 -0700

> we do this in an extension, again?

+1

---

From: Jason Greene <[email-masked]>
Date: Thu, 10 Jul 2014 13:15:15 -0500

>> we do this in an extension, again?

The length settings in the proposal already serves the same purpose that an extension to go larger would, and they also allow you to have small frames. A benefit would be to save a couple bytes in the header when an implementation only plans to allow 16KB frames. However, if that was important you could also create a size encoding rule without an extension. 

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat

---

From: Greg Wilkins <[email-masked]>
Date: Fri, 11 Jul 2014 09:11:53 +1000

> we do this in an extension, again?

Because it is yet unclear if there will actually be a viable extension eco
system, which will allow new extensions to be defined and deployed.

cheers

-- 
Greg Wilkins <[email-masked]>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.

---

From: Nicholas Hurley <[email-masked]>
Date: Thu, 10 Jul 2014 16:39:07 -0700

Which is why we should make sure that there are extensions that people want
to use, as soon as the spec is ready. I see no reason why exceedingly large
frames (along with altsvc, which I *definitely* want) can't be among that
list.

--
Peace,
  -Nick

On Thu, Jul 10, 2014 at 4:11 PM, Greg Wilkins <[email-masked]> wrote:

>> With the operative words there being "extended" and "option". So why
>> can't we do this in an extension, again?
>
>

---

From: Nicholas Hurley <[email-masked]>
Date: Thu, 10 Jul 2014 16:40:38 -0700

I see no convincing technical reasons in that list to make it a built-in
part of the protocol. It reads to me more like a list of "this would be
nice", which sounds just perfect for an extension.

--
Peace,
  -Nick

On Thu, Jul 10, 2014 at 11:15 AM, Jason Greene <[email-masked]>
wrote:

> The length settings in the proposal already serves the same purpose that
> an extension to go larger would, and they also allow you to have small
> frames. A benefit would be to save a couple bytes in the header when an
> implementation only plans to allow 16KB frames. However, if that was
> important you could also create a size encoding rule without an extension.
>
> --
> Jason T. Greene

---

From: Greg Wilkins <[email-masked]>
Date: Fri, 11 Jul 2014 11:05:43 +1000

> nice", which sounds just perfect for an extension.

Making it an extension does not allow CONTINUATIONS to be removed from the
protocol.   That puts it into other that "this would be nice" category.

You can't remove parts of the protocol in an extension.

regards

---

From: Jason Greene <[email-masked]>
Date: Thu, 10 Jul 2014 21:16:12 -0500

On Jul 10, 2014, at 8:05 PM, Greg Wilkins <[email-masked]> wrote:

> I see no convincing technical reasons in that list to make it a built-in part of the protocol. It reads to me more like a list of "this would be nice", which sounds just perfect for an extension.
> 
> Making it an extension does not allow CONTINUATIONS to be removed from the protocol.   That puts it into other that "this would be nice" category.
> 

You could remove CONTINUATION and then make everything else an extension, but then anything not using the extension can't send large headers nor decrease the frame size (which was mentioned as something someone might want to do).

I argue that the spec is just simpler and easier to follow if it's all together.

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 11 Jul 2014 21:44:50 +1200

> frames (along with altsvc, which I *definitely* want) can't be among that

There are a number of small problems to doing this as an extension. All
of which incrementally add up to the big problem of processing latency.

Making fields to hold non-16bit length values an optional field:

 Adds processing latency looking up two locations for the length value.

 Adds confusion over the meaning of any non-zero value stored in the
"normal" length field. Reintroducing potential for smuggling attacks
which HTTP/2 frame length was supposed to kill off.

 Adds ambiguity into where it is located in relation to all other
extensions optional fields. Because more than one extension may require
their optional field to be "first" after the default frame header all
such optional fields will require a type encoding prefix. Making it
bigger than necessary to hold just the length, and adding processing
latency to both find and verify.

We have large frames proposal to resolve all of these issues. Like Greg
said in the initial rationale of that thread. The proposed mechanism was
selected for its simplicity in resolving the issues at hand in threads
like this old one.

Amos

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 11 Jul 2014 10:05:50 +0000

>selected for its simplicity in resolving the issues at hand in threads

And I still think that proposal is the right way to go.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.