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

The memory needed for header interpretation will, for a decent
implementation, be at worst the sum of the size of the compression context
and the size of the receive buffer-- it will not expand once decompressed
unless a lot of useless copying is being done.

-=R


On Fri, May 10, 2013 at 2:08 PM, James M Snell <jasnell@gmail.com> wrote:

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