Subject: #541: Stateless Multiplexable Continuations

From: Mark Nottingham <[email-masked]>
Date: Fri, 27 Jun 2014 17:13:54 +1000

<https://github.com/http2/http2-spec/issues/541>

Given where we are in the process, the widespread support for the current continuation mechanism, and the running code we already have, this is going to be a hard sell. 

From what I can tell, there are a few people who are proponents of this, but the support is relatively weak; I don't yet hear anything saying that this is a must-have. 

Please tell me if I've got that wrong.

At any rate, I don't see us blocking on this issue; if it causes a lot more pain and interop issues, we can revisit after the next iteration.

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Jason Greene <[email-masked]>
Date: Fri, 27 Jun 2014 10:22:54 -0500

> Please tell me if I've got that wrong.

The problem is the existing CONTINUATION mechanism is HOL blocking, which is particularly bad for proxies. Consider this topology:

+----+                                      
|Evil+-----------+                          
+----+   h2      |                          
             +---v---+                      
+----+       |       |              +------+
| C1 +-------> Proxy +-------------->Origin|
+----+   h2  |       |  Coalesced   +------+
             +---^---+     h2               
+----+           |                          
| C2 +-----------+                          
+----+   h2                                 

If “evil" sends large headers, which forces the proxy to send CONTINUATION, then the coalesced connection to origin unfairly favors Evil impacting the QOS for C1 and C2. Even worse is if Origin rejects and refuses to process the CONTINUATION, thereby requiring it to down the coalesced connection and forcing the proxy to reestablish. QOS suffers.

Mitigation options are for a proxy not to coalesce connections, which gives up a significant benefit of HTTP/2, or to reject big CONTINUATIONS from “Evil". The problem with the latter is the proxy has no idea what Origin can and can not handle. 

The cost to fix this is minimal, and well worth eliminating HOL issues. Discouraging bloated headers is also a nice secondary benefit that many on this list have expressed interests in.

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat

---

From: Martin Thomson <[email-masked]>
Date: Fri, 27 Jun 2014 09:55:46 -0700

On 27 June 2014 08:22, Jason Greene <[email-masked]> 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

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

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.

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.

---

From: Jason Greene <[email-masked]>
Date: Fri, 27 Jun 2014 13:20:44 -0500

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

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

> with more diverse constituencies permit larger values.

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

> Allowing for multiplexing would be optimizing for a case that we don't

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