Re: #541: Stateless Multiplexable Continuations

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