Re: Questions on Frame Size

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 <jasnell@gmail.com> 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.
> On Jun 20, 2013 7:43 PM, "Shigeki Ohtsu" <ohtsu@iij.ad.jp> wrote:
>
>> 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<https://github.com/shigeki/http2-spec/compare/shigeki_20130621>
>>
>> If this is accepted, I will submit the PR.
>>
>> Regards,
>>
>> (2013/06/21 10:14), David Morris wrote:
>>
>>>
>>>
>>> On Fri, 21 Jun 2013, Amos Jeffries wrote:
>>>
>>>  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.
>>>
>>>
>>
>>

Received on Friday, 21 June 2013 03:02:01 UTC