Re: Large Frame Proposal

On Mon, Jul 7, 2014 at 11:17 AM, Willy Tarreau <w@1wt.eu> wrote:

> For example, the 0.02% you're talking about are the ones that *require*
> support for CONTINUATION in *all* implementations and which make all
> these implementations prone to slowloris-like attacks (for example).
>

There will always be attacks. We take one away, another will be created. We
can mitigate this one without changing the entire framing of the protocol.
For example, moving END_STREAM to CONTINUATION instead of HEADERS is a very
quick, easy indicator of whether or not the header block has more frames
coming. That makes it easier to decide whether or not to kill the
connection after the HEADERS frame. We could also make a change to indicate
the total size of the header block before sending anything, which also
mitigates the slowloris-style attack (at the expense of not being able to
stream HPACK - a tradeoff I am thinking more and more that I would be
willing to make).

I'm also still not convinced by the state commitment issue. It's entirely
possible for an endpoint to process and discard header data (thus
maintaining the shared state for the connection) without having to hold on
to the resulting headers. This means that endpoint is only keeping the
state that it has already committed to keeping (namely, the shared HPACK
state). So, it turns out, I was wrong, you don't have to send a GOAWAY, you
can actually keep your connection going. This also allows you to send back
an HTTP-level error (say 413) which will be easier for people to debug when
they're faced with a server/intermediary that doesn't want to handle the
headers they sent.

Also, the argument that CONTINUATION support is untested is also
unconvincing. I know I've tested my continuation support (both sending and
receiving), against a few different servers. While I'm sympathetic to the
argument that we should remove footguns/untested code, there are always
going to be bugs, and this change just trades one footgun (possibly
poorly-tested continuation support) for another (almost certainly
poorly-tested large frame support).


> Also concerning the numbers, I too have posted elements (please check
> the archives) indicating that video already represents 60% of the
> internet traffic and is deemed to 78% by 2018.


Let's please not conflate the issue of large headers with video. They're
only tangentially related - one is a correctness issue (large headers), one
is a performance issue. Let's assume some theoretical world where I end up
supporting large frames (VERY theoretical, at this point). If I don't know
that I'm receiving video, I don't want to advertise large frame support,
because when used poorly, that will kill multiplexing and priority, which
are essential to the non-video case. I generally won't know a priori
whether a connection I'm making will be used for video or not, so I don't
want to offer that performance footgun on every connection I make. And
while video is already a large percentage of the traffic, I haven't seen
any numbers so far that convince me it's a large percentage of the
connections. I'll say this again - I think jumbo/large/huge/whatever DATA
frames are a perfect candidate for an extension.
--
Peace
  -Nick