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

Re: #541: Stateless Multiplexable Continuations

From: Jason Greene <jason.greene@redhat.com>
Date: Fri, 27 Jun 2014 13:20:44 -0500
Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <53F7BC87-B7D5-4154-A962-D28F4B86605E@redhat.com>
To: Martin Thomson <martin.thomson@gmail.com>

On Jun 27, 2014, at 11:55 AM, Martin Thomson <martin.thomson@gmail.com> wrote:

> On 27 June 2014 08:22, Jason Greene <jason.greene@redhat.com> wrote:
>> The problem is the existing CONTINUATION mechanism is HOL blocking, which is particularly bad for proxies.
> This is absolutely true.  The fix, as we've discussed in the past is to:
> a) not send CONTINUATION, or

You canít not send a continuation if the client has > 16KB headers. So that option doesnít work. That is unless you reject > 16KB from the client. However then the large compatibility aspect is not preserved.

> b) wait for the entire header block before forwarding at the proxy and
> reject anything that is detectably evil.

That helps (assuming the required resources are available), however it still does not fix the QOS issue. The client sending the large header frame still gets multiple frames routed in preference to other clientís streams.

> The latter is a highly likely eventuality anyway, since certain
> critical routing fields are most likely to be found in the HPACK
> reference set, forcing the proxy to wait until the header block is
> complete before it can learn where to route the request (or whether to
> reject it).  Primarily, I'm thinking about `:scheme`.
> Yes, there is a concern about how the proxy determines how much is too
> much, but we've pretty good general guidance from this community
> already: 8k or thereabouts is a pretty reasonable limit, though those
> with more diverse constituencies permit larger values.

That effectively means no backwards compatibility though, which was the whole justification for CONTINUATION.

> The reasons that I still favour the blocking nature of CONTINUATION
> are that it creates a strong disincentive to use it (see above), and
> it does simply processing in the unlikely even that you do need to
> handle it.  CONTINUATIONS can be assembled (and streamed) at a layer
> just above framing, without having to invoke the rest of the state
> machine.
> Allowing for multiplexing would be optimizing for a case that we don't
> really want to support.

Itís actually optimizing everything OTHER than CONTIUATIONS which acts as a disincentive, instead of the big incentive you get using them today:

1) You can no longer abuse them as a high priority jumbo frame
2) Generating them is slight more involved
3) They take up a little more space
4) Other streams are not penalized by having their connection dropped under them.
5) They can be flow controlled 

Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
Received on Friday, 27 June 2014 18:21:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:31 UTC