Subject: Design Issue: Frame Size Items

From: James M Snell <[email-masked]>
Date: Tue, 7 May 2013 08:19:58 -0700

1. There is an existing ed note in the draft indicating that we
currently do not have any way of specifying the maximum frame size.
There are several possibilities:

  a. We decide we don't need to report a maximum frame size.
  b. We introduce a MAX_FRAME_SIZE setting for the SETTINGS frame.
  c. We add a headers block to the RST_FRAME and GOAWAY frames ;-) ..

  I think I prefer option (a) but (b) works too.

2. In the current draft we say that all implementations MUST be
capable of supporting frames up to 8192 octets in length. We don't
say, however, whether that size includes the 8-byte header or is that
just payload octets?

- James

---

From: Mike Bishop <[email-masked]>
Date: Tue, 7 May 2013 18:02:48 +0000

The reason this is a problem is that, if I accidentally violate your max frame size, you reset my stream.  At best, I resend the content in smaller frames; if that frame had a header block, though, we've corrupted the compression context and have to drop and restart the connection.  If that frame wasn't stream-related, there's no stream to reset, and we still have to drop and restart the connection.

So now I have to track the size of the frame you didn't like, and keep that as my new best guess at your maximum.  But it's not actually your maximum, it's a number I know is past your maximum.  So I may hit your actual maximum again with a future frame, hitting this problem over and over and asymptotically approaching your real maximum.

Better to know up front.  We can specify an initial (large) value and peers only need to change it if they need to restrict to a smaller value.  Of course, the client could exceed the server's limits with a huge HEADERS+PRIORITY before seeing the server's SETTINGS frame....

-----Original Message-----
From: James M Snell [mailto:[email-masked]] 
Sent: Tuesday, May 7, 2013 8:20 AM
To: [email-masked]
Subject: Design Issue: Frame Size Items

1. There is an existing ed note in the draft indicating that we currently do not have any way of specifying the maximum frame size.
There are several possibilities:

2. In the current draft we say that all implementations MUST be capable of supporting frames up to 8192 octets in length. We don't say, however, whether that size includes the 8-byte header or is that just payload octets?

- James

---

From: Martin Thomson <[email-masked]>
Date: Tue, 7 May 2013 11:07:28 -0700

>   a. We decide we don't need to report a maximum frame size.

This has been discussed.  The problem is that you have to then FIX the
maximum frame size and require that all implementations support that
size.  No one can decide on a goldilocks number: 4096, 8192, 16384,
32768 or 65536 have all been variously proposed.  Others want to add
extra bits to the length field to open up other options (i.e.,
petabytes).

>   b. We introduce a MAX_FRAME_SIZE setting for the SETTINGS frame.

This introduces another "known state" issue (see Gabriel's issues).
You have to have a default (see above), and then a robust way to
change.

>   c. We add a headers block to the RST_FRAME and GOAWAY frames ;-) ..

I'm not following you.

> say, however, whether that size includes the 8-byte header or is that

That's a simple fix.  Toss a coin.  ;)

---

From: Roberto Peon <[email-masked]>
Date: Tue, 7 May 2013 11:26:08 -0700

since a frame != the payload of a frame, I think the answer shouldn't be in
question.
A frame includes the framing and overhead bytes, and (regardless of how it
may have been done in the past) the frame-size field either corresponds to
this entity, or needs to be renamed.
-=R

---

From: James M Snell <[email-masked]>
Date: Tue, 7 May 2013 12:01:59 -0700

Roberto, not quite sure I'm following what you're saying. The answer
to what exactly shouldn't be in question?

---

From: James M Snell <[email-masked]>
Date: Tue, 7 May 2013 12:07:27 -0700

> You have to have a default (see above), and then a robust way to

Option (b) certainly isn't perfect but it works. Since our frame size
field is expressed as an unsigned 16-bit integer, we already have a
fixed maximum size (2^16-1 + 8) which ought to be the default
MAX_FRAME_SIZE. If an implementation needs it to be smaller, they can
specify so using the SETTINGS.

>>   c. We add a headers block to the RST_FRAME and GOAWAY frames ;-) ..

I was being silly.. never mind ;-)

> That's a simple fix.  Toss a coin.  ;)

Ok, coin toss says the 8-byte header is not included. That work for everyone?

- James

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 7 May 2013 16:41:34 -0300

Er, I meant 8192 octet max frames.

On Tue, May 7, 2013 at 4:41 PM, William Chan (陈智昌) <[email-masked]>wrote:

> I need to re-read the framing continuation thread (
> http://lists.w3.org/Archives/Public/ietf-http-wg/2013JanMar/0600.html),
> but I thought all this was addressed by that (8192 max frames, with frame
> continuation bit). I see that the spec does not mention frame
> continuations, so maybe we just have to write the text, or perhaps the
> thread reached a different conclusion than I remember.
>
>
> On Tue, May 7, 2013 at 12:19 PM, James M Snell <[email-masked]> wrote:
>

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 7 May 2013 16:41:06 -0300

I need to re-read the framing continuation thread (
http://lists.w3.org/Archives/Public/ietf-http-wg/2013JanMar/0600.html), but
I thought all this was addressed by that (8192 max frames, with frame
continuation bit). I see that the spec does not mention frame
continuations, so maybe we just have to write the text, or perhaps the
thread reached a different conclusion than I remember.

---

From: Roberto Peon <[email-masked]>
Date: Tue, 7 May 2013 13:18:46 -0700

Works for me.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 07 May 2013 20:41:56 +0000

In message <[email-masked]
.com>, Mike Bishop writes:

> Better to know up front.  We can specify an initial (large) value
> and peers only need to change it if they need to restrict to a
> smaller value.

I think you got that backwards...

The default limit needs to be small, until the server is willing to
invest resources in the client.

(Repeat after me: HTTP/2.0 SHALL make DoS attacks harder, not easier.)

-- 
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: William Chan (陈智昌) <[email-masked]>
Date: Tue, 7 May 2013 17:56:31 -0300

Beyond just the DoS impact, I think it's simply required from a correctness
perspective. Unlike our other limits in SETTINGS, this proposed one must
not be exceeded, since it's incorrect not to process control frames that
modify session state, like the compression context.

On Tue, May 7, 2013 at 5:41 PM, Poul-Henning Kamp <[email-masked]>wrote:

> In message
> <[email-masked]

---

From: Martin Thomson <[email-masked]>
Date: Tue, 7 May 2013 13:58:40 -0700

On 7 May 2013 12:41, William Chan (陈智昌) <[email-masked]> wrote:
> I need to re-read the framing continuation thread
> (http://lists.w3.org/Archives/Public/ietf-http-wg/2013JanMar/0600.html), but
> continuation bit). I see that the spec does not mention frame continuations,
> so maybe we just have to write the text, or perhaps the thread reached a
> different conclusion than I remember.

That discussion never really concluded.

What we have is MUST support 8192, but no upper limit (other than the
hard 65535 byte limit imposed by the frame length field size).

You might infer from this that 8192 is the only safe upper limit,
especially for frames containing headers.  Other frames might trigger
RST_STREAM, but at least you don't lose the session.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 7 May 2013 18:17:53 -0300

On Tue, May 7, 2013 at 5:58 PM, Martin Thomson <[email-masked]>wrote:

> continuations,

OK, I think we should conclude that thread :) I believe that resolving that
thread will resolve this issue.

> RST_STREAM, but at least you don't lose the session.

Yep, I indeed did infer that, since we don't (at least, that I know of)
have a safe mechanism for not processing frames that affect session state.

---

From: James M Snell <[email-masked]>
Date: Tue, 7 May 2013 21:31:59 -0700

Reading back over that thread, it seems to me that the overall
majority opinion was in favor of a smaller default max thread size
(let's just say 8192 + 8 byte header).

Proposal: Let's define that 8192+8 is the default MAX_FRAME size. If
an endpoint wishes to allow for frames larger or smaller than that, up
to ((s^16)-1)+8 total, then they can specify a SETTINGS_MAX_FRAME_SIZE
in the SETTINGS frame.

Yes, I know this proposal won't please everyone, but at some point we
need to put a stake in the ground on it. 8192+8 seems like a
reasonable enough of a default.

On Tue, May 7, 2013 at 2:17 PM, William Chan (陈智昌)
<[email-masked]> wrote:
> Yep, I indeed did infer that, since we don't (at least, that I know of) have
> a safe mechanism for not processing frames that affect session state.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 08 May 2013 06:34:36 +0000

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

>Proposal: Let's define that 8192+8 is the default MAX_FRAME size. 

8192 is a pretty arbitrary choice, wouldn't it make sense to do a
bit of math on typical MTU's and TCP/IP header sizes and see if
any numbers work out more optimal ?

---

From: James M Snell <[email-masked]>
Date: Tue, 7 May 2013 23:46:09 -0700

In this case it's not arbitrary at all, that's what's currently
written in the spec. At this point I'm just putting a stake in the
ground, there's plenty of time to fine tune it.

---

From: James M Snell <[email-masked]>
Date: Wed, 8 May 2013 12:49:21 -0700

Going back through this, here's a counter proposal:

Let's get rid of the 8192 frame size rule and simply say that the
maximum size for all DATA, HEADERS, HEADERS+PRIORITY and PUSH_PROMISE
frames is either 65,535 or the current flow control WINDOW_SIZE,
whichever is less. That way, if a device needs a smaller frame size,
it uses the existing flow control mechanisms to specify it.

Along with that, we would declare that flow control applies to header
bearing frames in addition to data frames and add language encouraging
implementations to never encode header bearing frames larger than the
current TCP MSS (if known)

- James

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 08 May 2013 20:56:59 +0000

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

>whichever is less.

Hmm, *now* you're talking...

I like it.