Re: Questions on Frame Size

[Amos Jeffries <[e-mail]>]

On 21/06/2013 10:29 a.m., Shigeki Ohtsu wrote:
> Sorry, I replied this only to James.  Re-sent it to WG again.
>
> (2013/06/21 1:29), James M Snell wrote:
>> 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.
>
> 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. "

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

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

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