Subject: Questions on Frame Size

From: Shigeki Ohtsu <[email-masked]>
Date: Thu, 20 Jun 2013 14:32:45 +0900

Hi,

The issues about frame size were discussed and might had some
agreements at SF interium but please let me ask some questions on the
current spec of "3.3.2 Frame Size" which is updated by
https://github.com/http2/http2-spec/commit/fd703b572cfc527582c0716e59f2c4044ae195a8

1. "For instance, individual DATA and HEADERS frames used to express
HTTP request and response messages (see Section 4) are not permitted
to exceed 16,383 octets of payload."

PUSH_PROMISE is not listed.
Is the data size of PUSH_PROMISE also limited to 16K or is it exceptional
for some reason?

2. "The absolute maximum amount of payload data any individual frame
 can contain is 65,535 octets. All implementations SHOULD be capable
 of receiving and minimally processing frames up to this size."

If PUSH_PROMISE has a 16K limit, the max frame size is still 64K,
however, any other frames besides DATA, HEADERS and PUSH_PROMISE
are only several octets at most.

Is it for the future extension not to change the frame length to 14bit?
If so, why the spec requires all implementations to support the 64K frame
 size only for the future extension?

Regards,

---

From: Roberto Peon <[email-masked]>
Date: Wed, 19 Jun 2013 23:44:58 -0700

The spec is in flux w.r.t. layering, where this will be clarified.
Right now, as I understand it, however, the intent is that HTTP will be
limited to 16k frame sizes, and anything larger would get you a protocol
error or similar.
-=R

---

From: Shigeki Ohtsu <[email-masked]>
Date: Thu, 20 Jun 2013 16:09:45 +0900

Thanks for your answer. I'm aware that the spec is still work-in-progress
for a new layering design but I was suprised that both two descriptions
about 16K limit and 64K requirements was newly added with the same commit.

The spec only covers HTTP so that the description of 64K requirements confused me.

(2013/06/20 15:44), Roberto Peon wrote:
> Right now, as I understand it, however, the intent is that HTTP will be limited to 16k frame sizes, and anything larger would get you a protocol
> error or similar.
> -=R
>
>
> On Wed, Jun 19, 2013 at 10:32 PM, Shigeki Ohtsu <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi,
>

---

From: James M Snell <[email-masked]>
Date: Thu, 20 Jun 2013 09:29:33 -0700

My understanding is...

When PUSH_PROMISE is used for HTTP, then yes, it would be limited to 16k.
When PUSH_PROMISE is used for any protocol other than HTTP, it could
be up to 64k.

We are defining the Framing Layer separately from the HTTP Layer in
order to allow other protocols to be built on top of the framing layer
at some point.

---

From: Shigeki Ohtsu <[email-masked]>
Date: Fri, 21 Jun 2013 07:29:18 +0900

Sorry, I replied this only to James.  Re-sent it to WG again.

> order to allow other protocols to be built on top of the framing layer

The spec would be applied to other protocols like SPDY but we should not
discuss it here because in "1.1 Document Organization" it says that

"While some of the framing layer concepts are isolated from HTTP, building
a generic framing layer has not been a goal. The framing layer is tailored
to the needs of the HTTP protocol and server push. "

and

"However, the ability to reuse the HTTP/2.0 framing layer is a non goal. "
in "5.1 Separation of Framing Layer and Application Layer "

We should start discussion at first whether we change them or not.

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 21 Jun 2013 12:47:32 +1200

> to the needs of the HTTP protocol and server push. "

Which implies that server-push is a different protocol to HTTP already.

> We should start discussion at first whether we change them or not.

I think it sufficient to mention that the framing layer MAY be re-used 
by protocols adhering to HTTP protocol semantics but that the frame 
design is making no special design decisions for that.

IIRC: the 64K limit is for next-generation requirements of systems 
running HTTP at TB speeds. Allowing new frames to be added for those 
larger line rates is very useful given they are already on the horizon 
and HTTP/2.0 has long lifetime ahead.

FWIW: I already have a few customers who would be thankful to send GB 
sized chunks between their servers, HOL blocking is not an issue there. 
But these are specialized use cases where custom frames can be used so 
long as any middleware is happy to relay the large entity/unknown frame 
size.

Amos

---

From: David Morris <[email-masked]>
Date: Thu, 20 Jun 2013 18:14:54 -0700 (PDT)

> Which implies that server-push is a different protocol to HTTP already.

Different from 1.1, but a new feature of 2.0

> IIRC: the 64K limit is for next-generation requirements of systems running
> HTTP at TB speeds. Allowing new frames to be added for those larger line rates
> is very useful given they are already on the horizon and HTTP/2.0 has long
> lifetime ahead.

In the SF Interim, we agreed to 64K/16K (frame/vs HTTP) to allow for the 
larger frame required to establish a TLS connection without added round
trips because the initial TLS setup exceeded a single frame.

---

From: Shigeki Ohtsu <[email-masked]>
Date: Fri, 21 Jun 2013 11:40:06 +0900

It seems that everyone agreed max 16K in HTTP but is not sure for use of 64K now.

I think it is a bad idea to require for all implementers to suport 64K frame size because
it is too early to discuss future extensions for non-HTTP protocols.

I've just made two commits for

1. change the requirement of min size of frame to 8K as previous one (maybe 16K is okay)
2. write max frame size of 16K explicity when carrying HTTP

https://github.com/shigeki/http2-spec/compare/shigeki_20130621

If this is accepted, I will submit the PR.

Regards,

---

From: James M Snell <[email-masked]>
Date: Thu, 20 Jun 2013 19:55:07 -0700

-1... At the face to face we hashed this out.  For the time being,  for the
current implementation draft, 16/64 is good enough.
On Jun 20, 2013 7:43 PM, "Shigeki Ohtsu" <[email-masked]> wrote:

> https://github.com/shigeki/**http2-spec/compare/shigeki_**20130621<https://github.com/shigeki/http2-spec/compare/shigeki_20130621>
>
>>> running

---

From: William Chan (陈智昌) <[email-masked]>
Date: Thu, 20 Jun 2013 19:56:14 -0700

> it is too early to discuss future extensions for non-HTTP protocols.

I think this argument is invalid. I would find it valid to say that this is
unnecessary complexity (having a larger max frame size at the framing
layer) since that's for non-HTTP protocols and it's too early to discuss
them. But if your implementation only going to support HTTP semantics
anyway and plans to choke if someone tries to send a frame for a non-HTTP
application layer protocol, then I don't think there's any additional
implementation burden here.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Thu, 20 Jun 2013 20:01:33 -0700

While I agree with your conclusion, I disagree with your explanation. I
think it's inappropriate to explain something as we hashed it out in the
f2f, sorry you weren't there to argue it.

This is also why I nitpick on commit messages that explain something as
"decided at f2f" without an explanation of the rationale.

On Thu, Jun 20, 2013 at 7:55 PM, James M Snell <[email-masked]> wrote:

> -1... At the face to face we hashed this out.  For the time being,  for
> the current implementation draft, 16/64 is good enough.

---

From: Shigeki Ohtsu <[email-masked]>
Date: Fri, 21 Jun 2013 12:53:16 +0900

Thanks for explaination.

I would be glad if you add some editors notes or whatever on the draft for about it.

I've amended the first commit to change the min frame size so that
it becomes just editorial fixes. I think it's more clear than before.

(2013/06/21 11:56), William Chan (陈智昌) wrote:
> On Thu, Jun 20, 2013 at 7:40 PM, Shigeki Ohtsu <[email-masked] <mailto:[email-masked]>> wrote:
>
> I think this argument is invalid. I would find it valid to say that this is unnecessary complexity (having a larger max frame size at the
> framing layer) since that's for non-HTTP protocols and it's too early to discuss them. But if your implementation only going to support HTTP
> semantics anyway and plans to choke if someone tries to send a frame for a non-HTTP application layer protocol, then I don't think there's any
> additional implementation burden here.
>
>
>     https://github.com/shigeki/__http2-spec/compare/shigeki___20130621 <https://github.com/shigeki/http2-spec/compare/shigeki_20130621>
>

---

From: Martin Thomson <[email-masked]>
Date: Fri, 21 Jun 2013 11:10:29 -0700

I've made a few changes.  Let me know if the current spec is somehow inadequate.

On 20 June 2013 20:53, Shigeki Ohtsu <[email-masked]> wrote:
>> I think this argument is invalid. I would find it valid to say that this
>> is unnecessary complexity (having a larger max frame size at the
>> framing layer) since that's for non-HTTP protocols and it's too early to
>> discuss them. But if your implementation only going to support HTTP
>> semantics anyway and plans to choke if someone tries to send a frame for a
>> non-HTTP application layer protocol, then I don't think there's any
>>     https://github.com/shigeki/__http2-spec/compare/shigeki___20130621
>> <https://github.com/shigeki/http2-spec/compare/shigeki_20130621>
>>
>>

---

From: Shigeki Ohtsu <[email-masked]>
Date: Sat, 22 Jun 2013 11:07:25 +0900

> I've made a few changes.  Let me know if the current spec is somehow inadequate.

Having a new subsection of "Frame Size Limits for HTTP" is good
as it's not redundant. Thanks.

Sometime later, we will need to change the description to
allow reuse of the frame layer for non-HTTP.

Regards,