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

From: James M Snell <[email-masked]>
Date: Wed, 8 May 2013 17:12:38 -0700

Suggested replacement text for the current "Frame Size" discussion in
the spec...

...
   While the flow control protocol and framing mechanisms defined by
this specification are largely independent of one another, the flow
control WINDOW_SIZE places an upper limit on the total amount of data
an endpoint can send to a peer at any given time. DATA, HEADERS,
HEADERS+PRIORITY and PUSH_PROMISE frame sizes MUST NOT exceed the
current WINDOW_SIZE for the stream or connection and MUST NOT be
greater than 65,535 bytes. The 8 bytes of the frame header are not
counted toward this limit.

   When a new connection is established, both endpoints are permitted
to begin sending frames prior to the establishment of an initial flow
control WINDOW_SIZE. Accordingly, there is a risk that an endpoint
might initially send frames that are too large for the peer to handle.
To mitigate this risk, it is RECOMMENDED that, until the initial
WINDOW_SIZE is established, the total size of individual
header-bearing frames not exceed the current TCP Maximum Segment Size
(MSS) and that individual DATA frames are no larger than 4096 bytes.
The 8-byte frame header is included in these limits.

If an endpoint is unable to process a frame due to its size and the
frame specifies any stream identifier field value other than 0x0, the
endpoint MUST respond with a <xref target="StreamErrorHandler">stream
error</xref> using the FRAME_TOO_LARGE error code. If the stream
identifier field value is 0x0, the endpoint MUST send a <xref
target="ConnectionErrorHandler">connection error</xref> using the
FRAME_TOO_LARGE error code.
...

- James

On Wed, May 8, 2013 at 1:56 PM, Poul-Henning Kamp <[email-masked]> wrote:
> In message <[email-masked]>
> , James M Snell writes:
>
>>Going back through this, here's a counter proposal:
>>
>>Let's get rid of the 8192 frame size rule and simply say that the
>>maximum size for all DATA, HEADERS, HEADERS+PRIORITY and PUSH_PROMISE
>>frames is either 65,535 or the current flow control WINDOW_SIZE,
>>whichever is less.
>
> Hmm, *now* you're talking...
>
> I like it.
>
> --
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> [email-masked]         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Thu, 9 May 2013 18:01:56 -0300

I discussed this with Roberto and Hasan. Here are some thoughts on
including header blocks within flow control:

* In the proposed text, it appears that only the compressed header block is
counting towards the window. Is that really what's desirable in order to
properly control memory? Processing the header block requires decompressing
it, and that's what will be kept in memory buffers until drained by the
sink.
* One problem with having headers count toward the per-stream flow control
window is that, in non-HTTP semantic layering, the header metadata could be
used as a control channel for the stream. Similar to how it would be
unfortunate to block connection control frames with the session flow
control window, it might also be unfortunate to block stream header/control
frames on the per-stream flow control window.
* As previously noted in other threads, it's unfortunate that stream
headers aren't counted toward any flow control windows, since that means we
may have to use the last-resort option to prevent further memory
consumption - stop calling read().

On Wed, May 8, 2013 at 9:12 PM, James M Snell <[email-masked]> wrote:

> > In message <
> [email-masked]>
> > , James M Snell writes:
> >

---

From: James M Snell <[email-masked]>
Date: Thu, 9 May 2013 14:20:34 -0700

On Thu, May 9, 2013 at 2:01 PM, William Chan (陈智昌)
<[email-masked]> wrote:
> I discussed this with Roberto and Hasan. Here are some thoughts on including
> header blocks within flow control:
>

Note that my proposal does not explicitly state that the header blocks
would be put covered by flow control, only that the current window
size be used to limit the maximum allowed size of those frames.
Whether or not headers count towards the flow control limits is a
separate (but definitely related) question... with that in mind, some
responses below...

> it, and that's what will be kept in memory buffers until drained by the

Yes, I think it is desirable. The memory management for the
decompressor state is separate from the notion of how much data the
receiver is willing to accept over the network. It's likely, for
instance, that the data in a DATA frame could be compressed as well.
It would not really make sense to count the decompressed bytes there
towards the flow control limits.

> unfortunate to block connection control frames with the session flow control
> window, it might also be unfortunate to block stream header/control frames
> on the per-stream flow control window.

Agreed. That said, however, because header blocks contain user
provided data, not including these in flow control opens the distinct
likelihood for abuse. For instance, if an application is not able to
get it's data passed through in DATA frames because of flow control
issues, they could simply bypass flow control by packaging the data up
into headers frames. Whether that's a realistic risk or not, I don't
know, but I've learned to never underestimate the ingenuity of
developers who are motivated enough to work around MUST and SHOULD
level requirements. :-)

- James

> * As previously noted in other threads, it's unfortunate that stream headers
> aren't counted toward any flow control windows, since that means we may have
> to use the last-resort option to prevent further memory consumption - stop
> calling read().
>
>
>> > In message
>> > <[email-masked]>
>> > , James M Snell writes:
>> >

---

From: James M Snell <[email-masked]>
Date: Fri, 10 May 2013 10:07:42 -0700

This is now pull request #92: https://github.com/http2/http2-spec/pull/92

---

From: Roberto Peon <[email-masked]>
Date: Fri, 10 May 2013 10:27:00 -0700

I'm strongly against including header frames in flow control.

Header frames and other control frames must not be part of the flow
control, else session flow control is useless. Session flow control exists
*to allow us to process header frames* and other control frames with a high
likelihood of not having to stop reading from the socket.

Flow control is never perfect, and implementations must already be ready to
cease reading from the socket. This is true regardless of whether header
frames are part of flow control

Since it might be conflated (I don't believe it was so far): as a reminder:
the number of header frames has zip to do with the size of the compressor
state, and, the number of streams also has zip to do with the size of the
compressor state.

Thus, the only thing we're worried about is the size of the receive buffer
and/or the size of the decompressed header. And, if an implementation
believes that it is hitting its memory limit, it does need to stop reading
from the TCP buffer or decompressing the headers. Since the decompressor
would have to know the size of the output that it is creating, passing a
constant to it would suffice to ensure that it can cease processing before
hitting whatever arbitrary memory limit.
Furthermore, a reasonable implementation of the compressor will not create
many copies of the headers, but rather give you immutable pointers to them
(with the memory resident either in the receive buffer, or in the
compression context), which means that the amount of memory used by
decompressing headers is likely to be orders of magnitude smaller than the
size of the receive buffer.

Again, I'm very strongly against including header frames in the flow
control limit.

-=R

On Thu, May 9, 2013 at 2:20 PM, James M Snell <[email-masked]> wrote:

> control
> headers

---

From: James M Snell <[email-masked]>
Date: Fri, 10 May 2013 10:34:08 -0700

On Fri, May 10, 2013 at 10:27 AM, Roberto Peon <[email-masked]> wrote:
> Header frames and other control frames must not be part of the flow control,
> else session flow control is useless. Session flow control exists *to allow
> us to process header frames* and other control frames with a high likelihood
> of not having to stop reading from the socket.
>

To be clear: this proposal *does not* put header and control frames
into flow control. It does, however, use the WINDOW_SIZE as a max-size
for headers frames. The data contained in the headers frames, however,
are not counted towards the flow control limits. In fact, this
proposal makes ZERO changes to the existing flow control mechanism. It
is focused 100% on frame size ONLY.

ALL this proposal is doing is using the window_size as a reasonable
limitation for frame size (particularly given that an endpoint will
rarely, if ever, desire for an individual frame to ever exceed the
WINDOW_SIZE).

> Again, I'm very strongly against including header frames in the flow control
> limit.
>
>
> -=R
>
>
>

---

From: William Chan (陈智昌) <[email-masked]>
Date: Fri, 10 May 2013 14:40:01 -0300

Personally, I'm not sure if there's enough "rough" consensus here yet to
commit anything. Just my two cents there.

> > separate (but definitely related) question... with that in mind, some

Thanks for the clarification, I did indeed misunderstand that. What's
supposed to happen when the initial per-stream window is set to be smaller
than what's necessary for a HEADERS+PRIORITY frame? We just never send the
HTTP message then? Or are we going to move forward with the frame
continuation bit?

> > towards the flow control limits.

I'm trying to figure out if I'm misunderstanding you or you're
misunderstanding the concern. Let me give a concrete example, an HTTP/2
proxy. When forwarding DATA frames, it doesn't have to decompress unless it
wants to inspect the payload for some reason. It just forwards onward to
the sink, unless the sink is not ready, in which case it buffers the frame
(agnostic of whether or not it's compressed). On the contrary, for a
HEADERS+PRIORITY frame, and IIUC, it *has* to decompress the header block
to update the compression context appropriately without introducing HoL
blocking with other things using the compression context. And if the sink
is not ready to accept the headers, and then it most likely has to keep the
decompressed header block around. That's my understanding at least, what
did I miss?

---

From: Martin Thomson <[email-masked]>
Date: Fri, 10 May 2013 10:44:28 -0700

> I'm strongly against including header frames in flow control.

I'll point out that this would also complicate the processing in a
sender quite a lot.  Headers are serialized on a session basis.  If
headers were subject to per-stream back pressure then it would be
necessary to delay encoding until the frame is committed to the send
buffer.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 10 May 2013 10:54:20 -0700

On 10 May 2013 10:40, William Chan (陈智昌) <[email-masked]> 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).

---

From: James M Snell <[email-masked]>
Date: Fri, 10 May 2013 11:23:18 -0700

On Fri, May 10, 2013 at 11:11 AM, Roberto Peon <[email-masked]> wrote:
> The continuation bit is necessary for headers at a minimum, as we do have
> headers which are > 65k, and something indicating either
> end-of-semantic-header-block is necessary to support that.
>
>
> I don't understand why it makes sense to limit header frames by the window
> size.
> what if the window size is zero?
> What if it is 1 byte.
>

If the window size is unreasonably low, then communication would not
be possible. Simple as that.

Or, we can go ahead and set a lower-bound also.. say frame size is <=
min(WINDOW_SIZE,65k) && > 1k .. the low bound is fairly arbitrary and
we can set that at whatever is reasonable.

The rationale for tying this to window size is to limit the number of
knobs that have to be turned to control the communication flow. window
size is already established as the amount of data the receiver is
willing to accept at any given time, it's reasonable to consider that
significant thought will have gone into establishing that window size
and that it will be tuned to achieve maximum network utilization.

- 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 <[email-masked]> 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 <[email-masked]>
>> wrote:
>>>

---

From: James M Snell <[email-masked]>
Date: Fri, 10 May 2013 10:58:24 -0700

> commit anything. Just my two cents there.

Agreed. I created a branch and the pull request to track to proposal.
I will keep the branch up to date as we go until there is either a
consensus to commit or an alternative is accepted.

> HTTP message then? Or are we going to move forward with the frame

The limit only effects individual frames, so the option here would be
to go with the continuation bit.

> wants to inspect the payload for some reason. It just forwards onward to the
> sink, unless the sink is not ready, in which case it buffers the frame
> HEADERS+PRIORITY frame, and IIUC, it *has* to decompress the header block to
> update the compression context appropriately without introducing HoL
> blocking with other things using the compression context. And if the sink is
> not ready to accept the headers, and then it most likely has to keep the
> decompressed header block around. That's my understanding at least, what did
> I miss?
>

The decompressor state is going to have it's own limit that is
independent of the frame size. I'm understanding what you're saying
but what I'm saying is that what you're describing is a different
issue.

- James

---

From: Martin Thomson <[email-masked]>
Date: Fri, 10 May 2013 11:50:46 -0700

> While I love the idea of limiting frames to 65535B, I hate the idea of a

Yeah, but perhaps you can reserve that hatred for the requests (and
responses) that have so many headers that they are larger than 64K.
Compressed.  :)

Most uses of the protocol wont see a continuation bit in use (which
suggests another problem).

---

From: William Chan (陈智昌) <[email-masked]>
Date: Fri, 10 May 2013 16:05:29 -0300

> and that it will be tuned to achieve maximum network utilization.

I don't really understand the point of this halfway stance of not counting
towards the window, yet having the frame size be bounded by the window.
DATA frames count towards the window, and their frame sizes are bounded by
the window as well (otherwise it'd be a PROTOCOL_ERROR). All the control
frames don't count towards any flow control window, and don't have their
frame sizes bounded by any window either.

I kinda get the impression from reading this email of yours that you think
window sizes are fairly static, and while it's true that the target window
size may be somewhat static (target the size to match the buffers), in
practice window sizes as viewed by the sender shrink and grow (every time
you send bytes, you use up more of the window(s) and hence it shrinks, and
requires a WINDOW_UPDATE to grow it(them)). If the sender sends data faster
than the receiver can process, I believe that the connection window will be
0 (from the sender's perspective, although a WINDOW_UPDATE may be incoming
to increase the window), which will block the sender from sending any
header frames.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Fri, 10 May 2013 15:51:05 -0300

On Fri, May 10, 2013 at 2:58 PM, James M Snell <[email-masked]> wrote:

> >> This is now pull request #92:
> https://github.com/http2/http2-spec/pull/92
> >>
> the
> did

I read Roberto's email and this mostly makes sense to me now (I didn't
realize that decompressing would use pointers into the compression context
rather than copying, that was the missing context leading to
misunderstanding here). I think there are some adversarial cases where this
doesn't work, but that's OK.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 10 May 2013 19:28:25 +0000

In message <[email-masked]>

>responses) that have so many headers that they are larger than 64K.

I think we should not have a continuation bit:  It will be seldomly
used, goes directly to the heart of memory management, it will
practically be an invitation for DoS attempts.

---

From: James M Snell <[email-masked]>
Date: Fri, 10 May 2013 12:50:09 -0700

On May 10, 2013 12:05 PM, "William Chan (陈智昌)" <[email-masked]>
wrote:
> I don't really understand the point of this halfway stance of not
counting towards the window, yet having the frame size be bounded by the
window. DATA frames count towards the window, and their frame sizes are
bounded by the window as well (otherwise it'd be a PROTOCOL_ERROR). All the
control frames don't count towards any flow control window, and don't have
their frame sizes bounded by any window either.

Other control frames don't contain arbitrarily large sets of user or
application provided data like header bearing frames do.

> I kinda get the impression from reading this email of yours that you
think window sizes are fairly static, and while it's true that the target
window size may be somewhat static (target the size to match the buffers),
in practice window sizes as viewed by the sender shrink and grow (every
time you send bytes, you use up more of the window(s) and hence it shrinks,
and requires a WINDOW_UPDATE to grow it(them)). If the sender sends data
faster than the receiver can process, I believe that the connection window
will be 0 (from the sender's perspective, although a WINDOW_UPDATE may be
incoming to increase the window), which will block the sender from sending
any header frames.

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.

---

From: Roberto Peon <[email-masked]>
Date: Fri, 10 May 2013 11:11:55 -0700

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 <[email-masked]> wrote:

> On Fri, May 10, 2013 at 1:54 PM, Martin Thomson <[email-masked]>wrote:
>

---

From: William Chan (陈智昌) <[email-masked]>
Date: Fri, 10 May 2013 17:00:05 -0300

> doesn't want the sender to initiate any new requests or to send arbitrarily
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.

> having

---

From: Roberto Peon <[email-masked]>
Date: Fri, 10 May 2013 13:15:40 -0700

This (lack of a continuation bit) would make it impossible to communicate
large headers, ones which are successfully transmitted today.

The alternative would be to have significantly larger frame sizes which is
in no way better from a memory size or buffer management perspective.

With the proposed default of 4k (which endpoints can extend to larger sized
after one RTT), it is likely that we will need to use the continuation bit
often enough that it should not suffer from the backup generator problem.
-=R
On May 10, 2013 12:28 PM, "Poul-Henning Kamp" <[email-masked]> wrote:

> In message <
> [email-masked]>
> , Martin Thomson writes:

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 10 May 2013 20:27:41 +0000

In message <CAP+FsNd2L3m8i+eTZ+=[email-masked]>

>large headers, ones which are successfully transmitted today.

Too bad:  Those demented people will have to stay on HTTP/1.1 then.

---

From: James M Snell <[email-masked]>
Date: Fri, 10 May 2013 14:08:48 -0700

On Fri, May 10, 2013 at 1:00 PM, William Chan (陈智昌)
<[email-masked]> wrote:
[snip]
>> 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.
>
> 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

---

From: "Martin J. Dürst" <[email-masked]>
Date: Sat, 11 May 2013 09:33:53 +0900

Hello Poul-Henning,

On 2013/05/11 5:27, Poul-Henning Kamp wrote:
> In message<CAP+FsNd2L3m8i+eTZ+=[email-masked]>
> , Roberto Peon writes:
>

It's probably true that whoever uses more than 64K of headers today 
isn't doing a very good job, to say the least. But you said that we 
should be planning for HTTP/2.0 to last for the next 10 or 20 years. I 
don't pretend I can predict how reasonable header size will grow over 
such a time span, but I'm rather sure it will grow.

Regards,    Martin.

---

From: Roberto Peon <[email-masked]>
Date: Fri, 10 May 2013 18:30:24 -0700

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 <[email-masked]> wrote:

> time.
> frame
> >> >> > On Fri, May 10, 2013 at 10:58 AM, Hasan Khalil <[email-masked]
> >
> >> >> > wrote:
> >> >> >>
> >> >> >> While I love the idea of limiting frames to 65535B, I hate the
> idea
> >> >> >> of a
> >> >> >> continuation bit.
> >> >> >>
> >> >> >>     -Hasan
> >> >> >>
> >> >> >>

---

From: Martin Thomson <[email-masked]>
Date: Fri, 10 May 2013 20:01:51 -0700

> unless a lot of useless copying is being done.

I was going to say the same thing until I realized that most APIs will
be forced to decode Huffman-encoded strings to present.  Some
implementations might avoid this entirely, others might defer
decompression, or something along those lines, but there is probably
going to be at least some exposure to the decompressed data.

---

From: Roberto Peon <[email-masked]>
Date: Fri, 10 May 2013 20:15:54 -0700

For implementations that don't care about memory efficiency, you're right
that they'll unencode the huffman-encoded strings. :)

The majority of non-efficiency-oriented APIs I've used treated the overhead
of HTTP and IO as insignificant, and likely just wouldn't care about this
at all.
-=R

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sat, 11 May 2013 08:03:43 +0000

In message <[email-masked]>, =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3
Qi?= writes:

>I don't pretend I can predict how reasonable header size will grow over 

Only if we let it.

---

From: James M Snell <[email-masked]>
Date: Sat, 11 May 2013 10:21:36 -0700

I generally find it safer not to make any assumptions here about what
any given random implementation will or will not do. The best we can
do is provide some degree of protection against abuse in the protocol
definition itself. It doesn't have to be perfect, by any means, but it
does have to be somewhat reasonable. I'm perfectly fine with not
including HEADERS/PUSH_PROMISE in flow control but we ought to at
least place limits on exactly how much data is being passed in those
frames at any given time -- precisely because we don't know exactly
how those are going to end up being used long term and we do not want
to inadvertently encourage abuse.

If you want a sender to still be able to send HEADERS frames even if
the window size is 0 (or lower than we can reasonably encode a minimal
header block), then a compromise here is pretty simple:

For data frames, max frame size is min(WINDOW_SIZE, 65k) ...
For control frames (including HEADERS), max frame size is max(4k,
min(WINDOW_SIZE, 65k)) ...

This ought to give us a reasonable range to work within. It basically
just states that while control frames are not subject to flow control,
when constructing headers frames, the sender needs to take into
consideration whatever load the recipient may currently be
experiencing as expressed through flow control.

On Fri, May 10, 2013 at 8:15 PM, Roberto Peon <[email-masked]> wrote:
> of HTTP and IO as insignificant, and likely just wouldn't care about this at
> all.
> -=R
>
>

---

From: William Chan (陈智昌) <[email-masked]>
Date: Mon, 13 May 2013 15:03:28 -0300

I guess I didn't really buy the argument about breaking headers frames up
into smaller chunks. I kinda feel like, at least in typical HTTP semantics
use cases, you need the majority of headers before you can handle/route
anyway, so this chunking seems kinda ineffective.

My stance is this is added complexity to the spec. If we want more
complexity, then we need implementers asking for this. I'd like to see a
proxy/server implementer (PHK has already voiced some support) champion
this. What do others like Willy/Amos/Jeff/etc think about this proposal? If
proxy/server implementers think this is worth the extra complexity in the
spec, then fine by me.

On Sat, May 11, 2013 at 2:21 PM, James M Snell <[email-masked]> wrote:

> > On Fri, May 10, 2013 at 8:01 PM, Martin Thomson <
> [email-masked]>
> > wrote:
> >>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 13 May 2013 20:57:21 +0100

<hat="proxy implementer">
I can see utility in recommending (or even mandating) that certain header fields be placed at the beginning of a HEADERS frame for expedited processing by an intermediary.

I'd expect the set of headers fields to be a small finite set (if folks later find utility in always placing other header fields early in HEADERS frames they can always publish best practice guidance to that effect). 

I don't see a use case for anything more complicated than that. 

HTH
Ben

On 13 May 2013, at 19:03, William Chan (陈智昌) <[email-masked]> wrote:

> I guess I didn't really buy the argument about breaking headers frames up into smaller chunks. I kinda feel like, at least in typical HTTP semantics use cases, you need the majority of headers before you can handle/route anyway, so this chunking seems kinda ineffective.
> 
> My stance is this is added complexity to the spec. If we want more complexity, then we need implementers asking for this. I'd like to see a proxy/server implementer (PHK has already voiced some support) champion this. What do others like Willy/Amos/Jeff/etc think about this proposal? If proxy/server implementers think this is worth the extra complexity in the spec, then fine by me.
> 
>

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 13 May 2013 20:27:45 +0000

In message <CAA4WUYijhOjJ1fo7VhUD6ezsOGO9P5q9M=[email-masked]>
, =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= writes:

>I'd like to see a
>this.

Well, sorry to disappoint you, but I'm down to trying to reduce the
damage where and if I can.

The current proposal is about as far away form how I would like to
see HTTP/2.0 look as it can be:  Speculative, Complex, far too many
parameters and not in any way streamlined for high-speed hardware
based routing and processing.

In other words: The archetypical result of engineering by committee
to solve yesterdays problems.

---

From: James M Snell <[email-masked]>
Date: Mon, 13 May 2013 13:31:15 -0700

PHK,  can you please clarify what you mean when you say "current proposal".
Do you mean the current spec as a whole or my specific change proposal
re:frame size.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 13 May 2013 20:44:37 +0000

In message <CABP7RbfBuCtLpR7Y2Zz9o4m2BPLeoz9pwGYjmavx=[email-masked]>
, James M Snell writes:
>--047d7b33cf0ef7a49204dc9f65e6
>Content-Type: text/plain; charset=UTF-8
>

I meant the current spec as a whole.

I think your specific proposal is an improvement over the other
offered alternatives for this specific issue.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 13 May 2013 14:33:04 -0700

> FRAME_TOO_LARGE error code.

I think that there is good advice here, namely: don't send a frame
larger than the current window (actually, both of them) permits.

What bothers me is that this is the only control on frame size.  And
it's not a very good one.  Unless you are operating at the
teeny-window end of the flow control space, then you probably want a
wider open window than this.  And the commitment that processing a
frame of size X imposes is greater than the commitment that buffering
a frame of size X imposes.

I'm not sure that this solves the problem.  At least not all of it.

---

From: James M Snell <[email-masked]>
Date: Mon, 13 May 2013 14:45:20 -0700

I'm not convinced it completely solves the problem either, but it at
least does something. I have the distinct feeling that the *right*
solution won't truly become obvious until we get better implementation
and testing across the board.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Mon, 13 May 2013 18:58:18 -0300

That's kinda why I don't really want to take this change as is now. I'd
rather wait for more implementation experience. AFAICT, we have at least 3
very large scale SPDY server deployments (Google, Twitter, and Facebook),
and none of them have yet asked for this to be fixed. Maybe they're fine
with just not calling read() in these situations. I'd rather wait for
people deploying SPDY & HTTP/2.0 draft implementations to come back and say
that this is actually a problem and we need to fix it.

---

From: James M Snell <[email-masked]>
Date: Mon, 13 May 2013 15:03:52 -0700

Yep, that's perfectly fine. As I've said, I'm just making sure these
items are documented and tracked. It may be that things are just fine
the way they are but we won't know for certain until we've tested the
hell out of everything :-) (And to be completely honest, I'm not
really all that concerned with whether the large scale implementations
have issues with this... my concerns are more with devices and
implementations working at the lower-end of the spectrum)

On Mon, May 13, 2013 at 2:58 PM, William Chan (陈智昌)
<[email-masked]> wrote:
> with just not calling read() in these situations. I'd rather wait for people
> deploying SPDY & HTTP/2.0 draft implementations to come back and say that
> this is actually a problem and we need to fix it.
>
>

---

From: Patrick McManus <[email-masked]>
Date: Mon, 13 May 2013 18:27:21 -0400

> that this is actually a problem and we need to fix it.
+1 for running code.

We're at a point where most changes should be influenced by that; imo.