W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2013

Re: Proposal: New Frame Size Text (was: Re: Design Issue: Frame Size Items)

From: James M Snell <jasnell@gmail.com>
Date: Fri, 10 May 2013 14:08:48 -0700
Message-ID: <CABP7RbdnnCiDSDt5CwPfRYx-BGgz8eoMUDa2J4xaWztHkCbe+w@mail.gmail.com>
To: William Chan (陈智昌) <willchan@chromium.org>
Cc: Roberto Peon <grmocg@gmail.com>, Poul-Henning Kamp <phk@phk.freebsd.dk>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, Martin Thomson <martin.thomson@gmail.com>, Hasan Khalil <hkhalil@google.com>
On Fri, May 10, 2013 at 1:00 PM, William Chan (陈智昌)
<willchan@chromium.org> wrote:
[snip]
>>
>> I do not presume the Window to be static at all.  In fact, quite the
>> opposite,  I expect it to be quite variable.  I do not want header frames
>> that are beyond an endpoints ability to process at any given point in time.
>> It's conceivable that if the widow size is 0, the receiver really doesn't
>> want the sender to initiate any new requests or to send arbitrarily large
>> blocks of headers.
>
> I don't get it. Then what does a halfway stance buy you? If you really want
> to prevent them from sending data, say that headers are included in flow
> control. If you're only shrinking the max frame size, but we can use a frame
> continuation bit, or there's a lower-bound on the frame-size, then the
> receiver isn't able to prevent the sender from sending arbitrary amounts of
> header data, but it's just forcing the sender to break it up into smaller
> frame sizes.
>>

It's not about preventing the data from being sent at all, it's about
breaking it up into smaller, more manageable chunks that are easier to
preempt and deal with incrementally.

If an endpoint says that it's only capable of handling 10k of data at
a time, whats the utility in sending a single frame containing 64k of
compressed header data that could potentially expand significantly
once decompressed?

- James

>> >>
>> >>
>> >> - James
>> >>
>> >> > I don't see any real benefits for limiting control frames to anything
>> >> > having
>> >> > to do with the window size as compared to sending a SETTING and
>> >> > having the
>> >> > default before there and having it completely decoupled from window
>> >> > size,
>> >> > and I do see a number of complications and ewws :/
>> >> > -=R
>> >> >
>> >> >
>> >> > On Fri, May 10, 2013 at 10:58 AM, Hasan Khalil <hkhalil@google.com>
>> >> > wrote:
>> >> >>
>> >> >> While I love the idea of limiting frames to 65535B, I hate the idea
>> >> >> of a
>> >> >> continuation bit.
>> >> >>
>> >> >>     -Hasan
>> >> >>
>> >> >>
>> >> >> On Fri, May 10, 2013 at 1:54 PM, Martin Thomson
>> >> >> <martin.thomson@gmail.com>
>> >> >> wrote:
>> >> >>>
>> >> >>> On 10 May 2013 10:40, William Chan (陈智昌) <willchan@chromium.org>
>> >> >>> wrote:
>> >> >>> > [...] are we going to move forward with the frame
>> >> >>> > continuation bit?
>> >> >>>
>> >> >>> I think that this was implicit in our decision to limit frames to
>> >> >>> 65535 bytes (or less).
>> >> >>
>> >> >>
>> >> >
>> >
>> >
>
>
Received on Friday, 10 May 2013 21:09:44 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:13 UTC