Subject: Call for Consensus: Frame size (to address #553)

From: Mark Nottingham <[email-masked]>
Date: Sat, 12 Jul 2014 16:46:31 +1000

There has been a lot of discussion over the last two weeks about various proposals to address a number of issues. While we're not at the point where we have consensus to accept any of them wholesale, I do think we can reduce the surface area of the discussion by declaring consensus on the less controversial parts.

So: it appears that we have consensus to address issue #553 by:

* Expanding the frame size field to 24 bits
* Reserving additional bits to align 
* Adding a setting advertising the maximum frame size allowed by the recipient, with a default of 16K octets and a minimum of 256 octets

This would address (only) <https://github.com/http2/http2-spec/issues/553>. 

Does anyone have a problem with that, or further comments?

Regards,

--
Mark Nottingham   https://www.mnot.net/

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 12 Jul 2014 09:58:15 +0200

> Does anyone have a problem with that, or further comments?

Fine for me. +1

Willy

---

From: Roberto Peon <[email-masked]>
Date: Sat, 12 Jul 2014 01:14:18 -0700

I don't think alignment is important (the protocol is not guaranteed to
align anyway since payload is not required to be aligned, and so we'll end
up with unaligned loads on most streams..) but think it is OK either way.
-=R

On Sat, Jul 12, 2014 at 12:58 AM, Willy Tarreau <[email-masked]> wrote:

> > There has been a lot of discussion over the last two weeks about various
> proposals to address a number of issues. While we're not at the point where
> we have consensus to accept any of them wholesale, I do think we can reduce
> the surface area of the discussion by declaring consensus on the less
> controversial parts.
> >
> > * Adding a setting advertising the maximum frame size allowed by the
> recipient, with a default of 16K octets and a minimum of 256 octets
> >
> > This would address (only) <
> https://github.com/http2/http2-spec/issues/553>.
> >

---

From: Osama Mazahir <[email-masked]>
Date: Sat, 12 Jul 2014 08:14:43 +0000

So in down step situations (e.g. changing the max_frame_size from 16K to 1K), the requirement will be to follow the standard SETTINGS/SETTINGS_ACK procedure in that the endpoint advertising the max_frame_size reduction must still be able to receive the larger frames until the SETTINGS_ACK comes back (e.g. SETTINGS and the larger frame cross in-flight)?  I just want to make sure that we are not creating design holes where a legitimate sender will violate the receiver.
________________________________________
From: Willy Tarreau <[email-masked]>
Sent: Saturday, July 12, 2014 12:58 AM
To: Mark Nottingham
Cc: HTTP Working Group
Subject: Re: Call for Consensus: Frame size (to address #553)

Fine for me. +1

Willy

---

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Sat, 12 Jul 2014 17:35:17 +0900

On Sat, Jul 12, 2014 at 3:46 PM, Mark Nottingham <[email-masked]> wrote:

> This would address (only) <https://github.com/http2/http2-spec/issues/553
> >.
>
​I'm OK with this.

Best regards,
Tatsuhiro Tsujikawa​
​

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sat, 12 Jul 2014 09:07:16 +0000

In message <[email-masked]>, Mark Nottingham wri
tes:

>This would address (only) 
><https://github.com/http2/http2-spec/issues/553>. 
>

+1

I agree on reserving 8 bits, but alignment is not a good argument
to use, since frames are not naturally aligned in in the TCP stream.
(We could require padding to 4-byte align frames, but I doubt it
will buy us anything worth the trouble..)

I think the argument for reserving 8 bits should be that we want
to make sure we have space for future improvements.

-- 
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.

---

From: <[email-masked]>
Date: Sat, 12 Jul 2014 12:42:11 +0000

> Does anyone have a problem with that, or further comments?

Yes. I believe Patrick, Roberto, etc and the SPDY experience showed that 16K is a good default for multiplexing.

Just as a point of exactness, for the default you mean exactly 2^14, right? (i.e. NOT 2^14-1)

This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.

---

From: James M Snell <[email-masked]>
Date: Sat, 12 Jul 2014 07:41:38 -0700

+1.

---

From: Jason Greene <[email-masked]>
Date: Sat, 12 Jul 2014 12:43:22 -0500

+1

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

---

From: Jeff Pinner <[email-masked]>
Date: Sat, 12 Jul 2014 11:37:49 -0700

what's the purpose of reserving the bits.

If you have a setting you must use to advertise the ability to receive
more than 16k the extra reserved bits are pointless. At this point
just use a 31-bit length field.

---

From: Yoav Nir <[email-masked]>
Date: Sun, 13 Jul 2014 15:38:28 +0300

> Does anyone have a problem with that, or further comments?

No problems for me, but at least some of the advocates for this change wanted separate settings for DATA vs HEADER frames (or more likely, DATA vs everything else). If that’s controversial, I think it’s fine to have a single setting now.

I also agree with Roberto and Poul-Henning that alignment is not likely to matter much. I also don’t believe we need to reserve those bits for future extension of the length field. If we ever want to expand the frames beyond 16 MB, then it’s going to be a very different protocol (where we don’t care about interactivity) or a very different Internet (where sending a >16 MB buffer does not hurt interactivity), so it’s not likely that a protocol we make now will fit anyway. So IMO room for expanding the length field and alignment are not reasons to reserve bits. That said, leaving room for more flags may or may not be a worthy goal, so we might as well have it.

Yoav

---

From: Erik Nygren <[email-masked]>
Date: Sun, 13 Jul 2014 15:59:35 -0400

+1 to expanding to 24 bits with a setting (while 16k may be good based on
current data, experience has shown that these sorts of things change
dramatically over a decade or two).

Where does the 256 octet minimum come from?  That seems like an arbitrary
value.  Is it too low?   The minimum values have ended up mattering in
other protocols  (the IPv4 minimum bleeding over into impacting DNS, etc)
so we should be careful not to set it too low.

     Erik

---

From: Martin Thomson <[email-masked]>
Date: Sun, 13 Jul 2014 13:12:03 -0700

On 13 July 2014 12:59, Erik Nygren <[email-masked]> wrote:
> value.  Is it too low?   The minimum values have ended up mattering in other
> protocols  (the IPv4 minimum bleeding over into impacting DNS, etc) so we
> should be careful not to set it too low.

That's basically the smallest unit that anyone could imagine being
useful.  (PHK cites GET /robots.txt as needing less than that much for
uncompressed header fields.)

The concerns around MTU and all that aren't really relevant here, so a
really small minimum is OK.

---

From: Jeff Pinner <[email-masked]>
Date: Sun, 13 Jul 2014 14:23:08 -0700

So am I to read this as a client might advertise a max frame size of
256 bytes and then request a 2GB file?

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sun, 13 Jul 2014 21:31:19 +0000

In message <[email-masked]>, Erik Nygren writ

>so we should be careful not to set it too low.

It's my back-of-the-envelope calculation for minimum interop.

256 bytes is enough to do "GET /" and get a redirect back, and to
"GET /robots.txt" and get a "deny all" back.

There are plenty of non-browser web-apps which can function in 256 bytes
and therefore there is no reason for us to insist the accept larger frames.

(I'd appreciate somebody else confirm my estimate)

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sun, 13 Jul 2014 21:40:16 +0000

In message <[email-masked]>, Jeff Pinner writ

>256 bytes and then request a 2GB file?

yes.

And the server is free to return 418 or react in any other way it might
find appropriate.

---

From: Jeff Pinner <[email-masked]>
Date: Sun, 13 Jul 2014 14:49:42 -0700

> And the server is free to return 418 or react in any other way it might

assuming i've already returned the 418, what would the suggestion be?

I'm assuming RST_STREAM with some error code, not sure which one
though -- do we need a new one?

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sun, 13 Jul 2014 21:52:52 +0000

In message <[email-masked]>, Jeff Pinner writ
>assuming i've already returned the 418, what would the suggestion be?

Whatever you like.

If you think it is a DoS of some kind, just RST it.

If you think the user is doing something stupid, return them a 200 and
tell them to download the file from another computer ?

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 14 Jul 2014 10:32:25 +1000

I'm good with this and think it is a good step to clear the decks.

With regards to 4 byte alignment, I'm not that concerned eitherway.
However if there are those that are really concerned about alignment, then
I think the best solution would be to move the padding length to the header
and require (or suggest?) that all frames are padding to a 4 byte boundary
(but make that a separate proposal if you want it).

regards

-- 
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: Yoav Nir <[email-masked]>
Date: Mon, 14 Jul 2014 12:03:22 +0300

> And the server is free to return 418 or react in any other way it might

“free to” yes, but if we’re going to say that clients advertise a max frame size that MUST be at least 256 bytes, then we should have a SHOULD-level requirement for servers to work with such a limit. Of course if the server has some heuristic that determines that a client is performing an attack, this SHOULD-level requirement can go out the window, but we do want to promote interoperability, so absent evidence of wrong-doing, the server SHOULD work with this. 

If we think that 256 bytes is too low to require servers to work with, then maybe we should set the min-max-frame to something higher, perhaps with some text that clients and servers MAY advertise and honor lower values by prior agreement. But if we say “plug a number here between 256 and 16,777,215”, then the protocol should work with all these values.

Yoav

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 14 Jul 2014 09:21:13 +0000

In message <[email-masked]>, Yoav Nir writes:

>> In message <[email-masked]>, Jeff Pinner writes:
>> 
>'free to' yes, but if we're going to say that clients advertise a 
>max frame size that MUST be at least 256 bytes, then we should have a 
>SHOULD-level requirement for servers to work with such a limit.

How is a client advertising 256 bytes different from a server
advertising a 256 byte max frame ?

And what exactly would the SHOULD level requirement make anybody do
differently anyway ?

>If we think that 256 bytes is too low to require servers to work with, 
>then maybe we should set the min-max-frame to something higher, [...]

Why should we force applications for whom 256 is plenty to use something
higher ?  Who gains anything by us doing so ?  And if we insist on some
lower limit which is onerous for tiny devices, do you think they are
going to spend 8 times more for their microcontroller or ignore what
we say ?

The 256 limit is simply to make sure that any HTTP/2 implementation will
always support "GET /" and "GET /robots.txt" and nothing more.

---

From: Yoav Nir <[email-masked]>
Date: Mon, 14 Jul 2014 12:59:55 +0300

> advertising a 256 byte max frame ?

No different at all. It was just more convenient that writing “one side” and “other side” all the time.

> And what exactly would the SHOULD level requirement make anybody do

It means that if you are creating a client (or server) that supports HTTP/2, then you SHOULD be able to work with a server (or client) that advertises a 256-byte max-framesize. Otherwise we get two perfectly legitimate implementations that fail to interoperate. That’s a bad thing.

> always support "GET /" and "GET /robots.txt" and nothing more.

They won’t be able to support “GET /robots.txt” if the other implementation blocks with a strange new status code whenever max-framesize is set to 256.

Yoav

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 14 Jul 2014 12:02:45 +0000

In message <[email-masked]>, Yoav Nir writes:

>It means that if you are creating a client (or server) that supports
>HTTP/2, then you SHOULD be able to work with a server (or client) that
>advertises a 256-byte max-framesize. Otherwise we get two perfectly
>legitimate implementations that fail to interoperate. That's a bad
>thing.

That SHOULD does not make any sense to me.

Do you want us to also include SHOULD requirements for 257, 258,
512, 1024, 1536, 2048 ... ?

Once you realize that 256 is not magic, your SHOULD requirement
reduces to:

	HTTP/2 implementations SHOULD be able to work with any other
	HTTP/2 implementation.

...which I really hope we don't need to tell people.

I also personally have a hard time seeing what I would code differently
to interoperate with a peer announcing 256 as opposed to 16k or 1MB
max frame size:

	frame_size = min(his_settings, my_preference);

What am I missing ?

---

From: Yoav Nir <[email-masked]>
Date: Mon, 14 Jul 2014 16:02:28 +0300

> Do you want us to also include SHOULD requirements for 257, 258,

We should tell them how.

> 	frame_size = min(his_settings, my_preference);

Down-thread, Jeff asked "So am I to read this as a client might advertise a max frame size of 256 bytes and then request a 2GB file?”, and you answered, "Yes. And the server is free to return 418 or react in any other way” 

I’m saying that if whenever a client announces 256 some servers will send an error code, we have a problem - we don’t have interoperability.

Yoav

---

From: <[email-masked]>
Date: Mon, 14 Jul 2014 13:42:27 +0000

On Monday,14 July 2014 11:21, [email-masked] wrote:
> higher ?  Who gains anything by us doing so ?  And if we insist on some lower
> limit which is onerous for tiny devices, do you think they are going to spend 8
> times more for their microcontroller or ignore what we say ?

I think the issue can be broken down as follows:

1) What, if anything, is required if an endpoint's peer advertises a MAX_FRAME_SIZE *greater* than 16K?
2) What, if anything, is required if an endpoints' peer advertises a MAX_FRAME_SIZE *smaller* than 16K?

For 1), greater than 16K,
I think the answer is obvious.  The endpoint can either ignore the setting from its peer and continue using 16K as a max frame size, or if the endpoint so chooses, use larger frames up to the MAX_FRAME_SIZE declared by its peer.

For 2), smaller than 16K,
the answer is not so obvious.  I brought this up before, but it was ignored.  Is the endpoint allowed to continue using any frame size up to 16K, or is the endpoint *required* to honor MAX_FRAME_SIZE?

Allowing an endpoint to ignore settings below 16K makes the setting symmetric i.e. MAX_FRAME_SIZE is optional either way.  It also allows simple implementations to use a fixed 16K frame buffer and ignore the setting altogether.

On the other hand, resource-constrained implementations (e.g. IoT devices) would benefit, as PHK points out, from being able to use a much smaller frame buffer and force the peer to send frames that small.

-keith

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 14 Jul 2014 14:18:59 +0000

In message <[email-masked]>, [email-masked] w
>   MAX_FRAME_SIZE *smaller* than 16K?

Substitute "whatever this endpoint prefers" for 16K, since 16K isn't magic either.

Answer:  Send frames no larger than the smaller of the two endpoints wants.

There can only ever be an issue with the first request, which is
typically sent before the peers SETTINGS arrive.

If this is a brand new contact, the client and server has never
seen each other before, the user typed a FQDN in the addressbar:
The request is "GET /" and the 256 byte limit is not a relevant
limit in practice, since it would take a FQDN that compresses
Host: to around 200 bytes before it fails.

If this is a brand new contact, the client followed a link on some
web-page:  There is a strong presumption that a "GET $url" will
fit in the servers MAX_FRAME_SIZE, otherwise the link is effectively
dead for everybody.

If the client has previously been in touch with another server in
the same domain cookies may be sent.

But if so, there is a very strong presumption that all the servers
of the domain will announce frames big enough to accept the cookies,
otherwise they would be dead for the world at large.  (This is
an adminstrative variant of the FQDN issue above.)

If the browser has contacted this server previously, it may have
cookies and other state (URL from bookmarks etc.)  here is also
every reason in the world to belive that this will fit in whatever
MAX_FRAME_SIZE the server tells us in a RTT:  That's how we got
the contact state in the first place.

If the first request on a connection is a PUT/POST or other request
with an entity-body, there is a valid question about what size of
DATA frame to send the entity body with ?

The answer is:  Send max(HEADERS.length, 256) byte DATA frames until
the SETTINGS have arrived from the other end.  The only cost is a
slightly higher transmission overhead for the first RTT (but better
multiplexing with other parallel requests).

So while there is a theoretical problem of a client connecting to
a server point blank and dumping XXkB frame on it, in practice that
only happens if the server has prevously revealed that it handles
that or if the client has hostile intent.

So no, all we need is a smallest MAX_FRAME_SIZE.

But do note that I also proposed that all implementations SHOULD
be configurable to 16KB.  People will probably take that as 
strong clue for their defaults.

---

From: Jeff Pinner <[email-masked]>
Date: Mon, 14 Jul 2014 08:18:42 -0700

With a 10 byte header (to fit a 32-bit length field), setting the
MAX_FRAME_SIZE to 256 is almost a 4% !! overhead in the transmitted
bytes just for framing the data.

I can't imagine I would do anything other than send a GO_AWAY and
close the connection.

Can we just keep the minimum frame size the same as today and use
settings to increase only?

The argument against doesn't make sense to me, embedded clients
already have to deal with a 16-bit IP length field so the idea that
they can't handle a 14-bit HTTP length field seems absurd.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 14 Jul 2014 15:21:44 +0000

In message <[email-masked]>, Jeff Pinner writ
>I can't imagine I would do anything other than send a GO_AWAY and

And that's fine, if you're sure you'll never download new firmware
to "intelligent lightbulbs" etc.

>settings to increase only?

Because that would force anybody with a small microcontroller to
be non-compliant for no good reason.

>they can't handle a 14-bit HTTP length field seems absurd.

They typically only have to deal with a single packet of their
chosen transport.  The rest can be held as state.

Please understand that the 256 is there to avoid people implementing
smaller limits, not larger limits.

---

From: <[email-masked]>
Date: Mon, 14 Jul 2014 20:09:39 +0000

> typically sent before the peers SETTINGS arrive.

Ok, now I understand. You're advocating for MAX_FRAME_SIZE to be a hard limit regardless of the default value. The default value of the setting is 16K, but an endpoint can immediately change that on connection open to something lower if it doesn't want to support 16K frames.  (This is also true with respect to the hpack table size setting default 4096 value.)

During the time between connection open and the ack of its settings, the endpoint has to decide to temporarily support frames up to 16K or RST_STREAM with STREAM_REFUSED and hope the client retries.

As I mentioned before, if I understood Jeff correctly, he didn't like this approach because he couldn't just always use a fixed 16K frame size.

-Keith

---

From: <[email-masked]>
Date: Mon, 14 Jul 2014 20:27:17 +0000

> bytes just for framing the data.

That's a trade off the embedded device has to decide to make when choosing 1) whether to use h2 at all*, and 2) what frame size to use.

*http used to be a no-brainier for many embedded devices

> I can't imagine I would do anything other than send a GO_AWAY and

Why? Would you consider it a DoS? The point of the minimum was to disallow setting MAX_FRAME_SIZE to 1 byte which would only be useful for a DoS.

> settings to increase only?

The point of the setting is to allow tuning the frame size up _and down_ for specific network conditions, etc.

e.g. Consider a mobile device that detects it's on a really slow network. It's in its best interest to tell the server to use smaller frames. Otherwise, as has been pointed out by Patrick, the server can't respond quickly to control frames from the client (e.g cancel stream).

> they can't handle a 14-bit HTTP length field seems absurd.

Your argument seems absurd :)

The device certainly doesn't receive 2^16 bytes in a single packet. There are micro-controllers that don't even have enough RAM to hold that much data. Rather, it will deal with the data packet-by-packet, frame-by-frame.

-Keith

---

From: Johnny Graettinger <[email-masked]>
Date: Mon, 14 Jul 2014 16:29:38 -0400

>
>
> Ok, now I understand. You're advocating for MAX_FRAME_SIZE to be a hard
> limit regardless of the default value. The default value of the setting is
> 16K, but an endpoint can immediately change that on connection open to
> something lower if it doesn't want to support 16K frames.  (This is also
> true with respect to the hpack table size setting default 4096 value.)
>
> During the time between connection open and the ack of its settings, the
> endpoint has to decide to temporarily support frames up to 16K or
> RST_STREAM with STREAM_REFUSED and hope the client retries.
>

I think it's worse than this, because if the client sent a frame larger
than the server's MAX_FRAME_SIZE immediately after connection, it was
probably a HEADERS frame, and that frame needs to be processed or the
compression context is hosed and the connection must be closed.

Basically the server has the choice of accepting 16K HEADERS frames
temporarily, or not talking to that client at all.

For that reason, I agree with Jeff that the default and minimum should be
the same.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 14 Jul 2014 20:38:55 +0000

In message <[email-masked]>, [email-masked] writes:

>Ok, now I understand. You're advocating for MAX_FRAME_SIZE to be a hard limit
>regardless of the default value.

What I'm advocating is that 

A) you can *always* get a 256 byte frame through.

and

B) that all software SHOULD be configurable to allow 16KB frames.

No more, no less.

>As I mentioned before, if I understood Jeff correctly, he didn't like this 
>approach because he couldn't just always use a fixed 16K frame size.

And as I analysed in my previous email:  In all the cases where
Jeff has an opportunity to do that, there is almost certainty that
it will always work.

The one case I can see where it might fail, is if Jeff tries to access an
"intelligent lightbulb" at edison.example.com, after example.com's main
websever stuffed his browser with 14 kB of cookies.

That's a corner-case I can live with.

---

From: Johnny Graettinger <[email-masked]>
Date: Mon, 14 Jul 2014 16:42:25 -0400

Expanding the thought:

If we allow the minimum to be smaller than the default frame size, we will
get servers who close connections (because they don't want to deal with
processing the frame, and RST_STREAM isn't an option), and we will get
clients who repeatedly spin up a new connection and retry the request.
They'll appear to inter-op correctly most of the time, so long as the
client's actual headers are within the server's frame limit. When they
don't work, though, we'll see lots of mysterious infinite retry loops :)

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 14 Jul 2014 20:43:11 +0000

In message <[email-masked]>, Johnny Graetting

>compression context is hosed and the connection must be closed.

Please see my previous email for analysis why this is simply not the
case.

If you disagree with my analysis please explain the scenario where
the client would send 16KB HEADERS to a device which have never
accepted frames larger than 256 bytes ?

Specifically, I want to know what's in that 16KB HEADER frame and
why it is there...

---

From: Jason Greene <[email-masked]>
Date: Mon, 14 Jul 2014 15:45:22 -0500

On Jul 14, 2014, at 3:29 PM, Johnny Graettinger <[email-masked]> wrote:

> I think it's worse than this, because if the client sent a frame larger than the server's MAX_FRAME_SIZE immediately after connection, it was probably a HEADERS frame, and that frame needs to be processed or the compression context is hosed and the connection must be closed.
> 
> Basically the server has the choice of accepting 16K HEADERS frames temporarily, or not talking to that client at all.
> 
> For that reason, I agree with Jeff that the default and minimum should be the same.

Just in case it was missed, there was extra low latency use cases discussed a week or two ago where you might want something like a 4k frame. It’s reasonable that a server can actually handle 16+ just fine, but some application/deployment wants to optimize in this area.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 14 Jul 2014 20:47:55 +0000

In message <CAEn92TpaQU2zpvcVP=[email-masked]>, Johnny Graetting

>clients who repeatedly spin up a new connection and retry the request.

This is simply not true.

Why would a client ever send a 16KB HEADERS to a lightbulb which never
has and never will emit a single set-cookies header ?

Only if a client, point blank, decides to send a request larger than the
server can handle, will there be a problem.

Please detail the scenarious where that happens ?

---

From: Jason Greene <[email-masked]>
Date: Mon, 14 Jul 2014 15:58:40 -0500

On Jul 14, 2014, at 3:42 PM, Johnny Graettinger <[email-masked]> wrote:

> Expanding the thought:
> 
> If we allow the minimum to be smaller than the default frame size, we will get servers who close connections (because they don't want to deal with processing the frame, and RST_STREAM isn't an option), and we will get clients who repeatedly spin up a new connection and retry the request. They'll appear to inter-op correctly most of the time, so long as the client's actual headers are within the server's frame limit. When they don't work, though, we'll see lots of mysterious infinite retry loops :)

I have wondered what the exact behavior should be for the case of hpack table size < 4k when this type of edge case occurs. The server can send SETTINGS_TIMEOUT, but that doesn’t really seem appropriate, since it just means it didn’t get the ACK fast enough, not hey don’t send anything before you read my settings. Perhaps we need a RETRY_USING_SETTINGS or something like that.

---

From: Johnny Graettinger <[email-masked]>
Date: Mon, 14 Jul 2014 17:02:03 -0400

I'm not that interested in talking about lightbulbs. These use cases can
appropriately be covered by h2-lowprofile / h2-c, and I've no objection to
a 256 byte default and minimum in that context.

People mis-configure software all the time. This is a foot-gun. Ex,
consider an admin for a deployed service who "tunes" their load-balancer
configuration to require smaller frames because they heard that'd improve
latency.

On Mon, Jul 14, 2014 at 4:47 PM, Poul-Henning Kamp <[email-masked]>
wrote:

> In message <CAEn92TpaQU2zpvcVP=_
> [email-masked]>, Johnny Graetting
> er writes:
>
> >Expanding the thought:
> >

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 14 Jul 2014 21:07:22 +0000

In message <[email-masked]>, Johnny Graetting
er writes:

>I'm not that interested in talking about lightbulbs

But the WG certainly is, it's in our charter to support non-browser APIs.

>configuration to require smaller frames because they heard that'd improve

How is that different from him "tuning" anything else while being
an idiot ?  Specifically, how is it different from him doing the same
idiotic thing to HTTP/1 today ?

Please come up with a serious and detailed example where this will not
just work out of the box ?

---

From: Jeff Pinner <[email-masked]>
Date: Mon, 14 Jul 2014 14:20:00 -0700

> The device certainly doesn't receive 2^16 bytes in a single packet. There are micro-controllers that don't even have enough RAM to hold that much data. Rather, it will deal with the data packet-by-…

And why would the device need to buffer the entire HTTP frame in memory?

How are the HTTP frames and different from the IP or TCP frames in
terms of buffering requirements?

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 14 Jul 2014 21:24:06 +0000

In message <[email-masked]>, Jeff Pinner writ
>And why would the device need to buffer the entire HTTP frame in memory?

Many of the "tiny" TCP stacks only have a single packet buffer, and the MTU
varies from ethernets 1500 down to the historical minimum MTU of 296 often
used on ad-hoc mesh-networks.

(that's actually an argument for using 256 - size of frame header for the limit)

---

From: <[email-masked]>
Date: Mon, 14 Jul 2014 21:29:49 +0000

On 14 Jul 2014, at 22:29, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:

I opened this very issue a few weeks ago.  I was told that if you set the table size to 0, you can rst_stream, but you don't have to close the connection. When the client retries it should have already seen your new settings with table_size=0 and max_frame=256, so all should be well.

---

From: <[email-masked]>
Date: Mon, 14 Jul 2014 21:34:16 +0000

On 14 Jul 2014, at 23:03, "[email-masked]" <[email-masked]> wrote:
>
> I'm not that interested in talking about lightbulbs. These use cases can appropriately be covered by h2-lowprofile / h2-c, and I've no objection to a 256 byte default and minimum in that context.

+1 for different profiles

But unfortunately as of today, no such profile(s) exist.  Roberto (and somebody else?) wrote a draft that suggested different profiles, but it didn't gain much traction.  I brought it up again several weeks ago, but all I heard was crickets.

---

From: <[email-masked]>
Date: Mon, 14 Jul 2014 21:37:40 +0000

> And why would the device need to buffer the entire HTTP frame in memory?

In addition to what PHK said, it is also very likely the device will need to buffer the headers frame (but as PHK also pointed out, there doesn't seem to be a use case for sending big headers to a device that doesn't send set-cookie and therefore doesn't expect cookie headers).

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 14 Jul 2014 21:42:46 +0000

In message <[email-masked]>, [email-masked] writes:
>On 14 Jul 2014, at 23:03, "[email-masked]" <jgraettinger@chromiu=
>m.org> wrote:
>>
>> I'm not that interested in talking about lightbulbs. These use cases can =
>appropriately be covered by h2-lowprofile / h2-c, and I've no objection to =

-1 for different profiles.

Show us the need before fragmenting the protocol.

---

From: Johnny Graettinger <[email-masked]>
Date: Mon, 14 Jul 2014 17:46:58 -0400

> I opened this very issue a few weeks ago.  I was told that if you set the
> table size to 0, you can rst_stream, but you don't have to close the
> connection. When the client retries it should have already seen your new
> settings with table_size=0 and max_frame=256, so all should be well.
>

This is true, you're correct. I do still think that requiring deployers of
HTTP/2 to be so intimately aware of the relationship b/w max frame size,
hpack table size, and sizes of compressed header sets sent from clients is
a bad idea, and wholly unnecessary.

> But unfortunately as of today, no such profile(s) exist.  Roberto (and
> somebody else?) wrote a draft that suggested different profiles, but it
> didn't gain much traction.  I brought it up again several weeks ago, but
> all I heard was crickets.

Speaking personally, I don't understand the use cases well enough. A
low-profile mode which uses base HTTP/2 framing but changes initial
settings makes plenty of sense to me. I don't understand well enough what
those limits ought to be, and am happy to let those who do drive that
process.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 14 Jul 2014 14:54:35 -0700

> Show us the need before fragmenting the protocol.

This was the conclusion we reached on that particular point.  The case
was made, but you have to make a pretty strong case before you do
something that drastic.

We didn't *completely* reject the idea, but noted that it needed a
much stronger reason to justify it.  Nothing we've talked about in the
last two weeks is actually new in that regard.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 15 Jul 2014 11:34:02 +1000

<https://github.com/http2/http2-spec/issues/553> is now marked as editor-ready, with consensus captured there.

I don't hear much controversy over 24 vs. 31 bits, so I'll leave it to the editor to come up with the exact format of the frame, based on the discussion. 

I do hear some pushback on the 256 byte minimum. Keeping in mind that the issue we're addressing is about recipient overhead in the other direction, as well as the potential impact on interop, I don't see consensus for such a low minimum. Let's keep the minimum at 16K for now; if anyone is sufficiently motivated, they can open a separate issue.

There was discussion a while back about not making this a granular setting (e.g., allowing any payload size between min and max to be set), and there seemed to be support for making it more coarse-grained (e.g., specifying the number of bits available in the field, so that the granularity is 2^n, leaving us with a setting of "14" to indicate 16K max frame size). I'll leave it to the editor to come up with a sensible scheme. 

If people have feedback about the choices the editor makes, I'm sure he'll be enchanted to hear about it.

Cheers,

P.S. This thread is drifting off into very exploratory / "we might need that" territory, and that's not good. Please stay focused on the actual issues, and remember that our charter is to replace HTTP for its common use cases, not to design a protocol for low-latency lightbulbs. Thanks.