Re: Stuck in a train -- reading HTTP/2 draft.

I'll give brief (as possible) replies to some points below, as they touch
on some of my points of chronic malcontent.   But in general, many of PHKs
comments reflect the surprise that a protocol educated reader gets from
looking at some of the design decisions in the draft whose motivation is
not entirely clear.


On 16 June 2014 23:30, Mark Nottingham <mnot@mnot.net> wrote:

> See input from PHK below, forwarded with permission.
>
> > From: "Poul-Henning Kamp" <phk@phk.freebsd.dk>
> > Subject: Stuck in a train -- reading HTTP/2 draft.
> > Date: 16 June 2014 10:50:31 pm AEST
> > To: Mark Nottingham <mnot@mnot.net>
>
>
> > Page 22ff: Priority
> > -------------------
> > It will also be the first thing implementors skip in order to get
> > something working fast, and they may never come back and implement
> > it, unless serious numbers show it's worth the complexity.
>
> We've skipped it an only intend coming back once we have more experience
of traffic with many parallel streams in operation.



> Page 28ff: Padding
> > ------------------
> > For this reason I would make padding part of the framing format,
> > rather than the individual message types.
>

I would prefer padding be removed totally.  But failing that, I would
prefer a padding frame that could be sent between other frames using one of
the reserved bits to indicate it is padding and a 7+ integer length field
so that it could be a 1 octet frame:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |1|R|Length (6+)|  Padding (0....                               |
    +-+-+-----------+-----------------------------------------------+


Failing that then on every frame is better than on specific frame types.

But my concern remains that the transport implementation has no idea what
to do with padding. When should it use it? how long it should be? what is
the best padding to use for given data. etc. etc.    The application is the
only thing that knows and given that most applications communicate with the
transport via a simple OutputStream style abstraction, there is no easy way
to communicate frame by frame padding.       I firmly believe that it is
just not the job of the transport to either provide or explicitly transport
padding.   This should be the job of either the encryption layer or the
application layer and neither needs support from the transport to do this.


> It's also pretty non-obvious why we need CONTINUATION in the
> > first place:  Why not simply send HEADERS until one of them has
> > the END_HEADERS bit set ?
>

It is indeed non obvious.  But I have tried many times to come up with a
way of removing them and I have concluded that they are a necessary
consequence of other design decisions - specifically the single shared
state table of header encoding.


> > For obvious DoS reasons, it's a mistake to not apply flowcontrol
> > to HEADERS.
>

Indeed.  However I do not think that strict DoS is the main concern
here.    Instead I believe there will eventually be collusions between
applications, clients and servers to use the lack of flow control to
attempt to gain benefits vs other traffic on shared connections.   Just as
browsers increased the HTTP/1.1 connection limit, non flow control of
headers represents an incentive to use headers for large traffic.  To think
that this will not be exploited is to under estimate human nature!

However, it is nigh impossible to flow control headers when we have decided
to have a single state table for non size limited header compression.
Lots of "ugly" design decisions that I commented on and now PHK is
commenting on, flow from that decision.

Currently the WG appears resolute to stick with the single state table
decision... but if there is any doubt, then I have some proposals that I
would be keen to expand on (but am currently not spending time on as I
don't think there is currently interest in revisiting this).



> > This is just asking for trouble...
> >
> >   The last frame in the sequence bears an END_STREAM flag, though a
> >   HEADERS frame bearing the END_STREAM flag can be followed by
> >   CONTINUATION frames that carry any remaining portions of the header
> >   block.
> >
> > The last frame should have the END_STREAM flag, always, there's
> > no excuse for "whoops" details like this.
>

Ah for this one I think I used the phrase "MASSIVE MISTAKE verging on
hubris" when I first read the spec to describe this particular uglyness:)

Again, I have come to understand that it is a logical consequence of other
design decisions - again rooted in the single header compression state
table. There is no easy fix within the current draft.

Essentially with the current design, HEADERS+CONTINUATION* has to be
treated semantically like a single frame and once you think like that, the
END_STREAM flag is on the last frame!   Logical, but ugly!

> Isn't this needlessly strict ?  No harm would come from DATA frames
> > or SETTING frames being stuffed in there.
>

See above.


> Page 51: Trailing headers
> > -------------------------
>

Or just punted to an extension.   Ie you can send streams with trailers (or
embedded headers), but they are just not HTTP streams.   ie in the same way
that websocket will eventually be carried in extended streams, any HTTP
like protocol that requires trailers can also be an extension.   We can
make them unsupported in the base protocol.

>From other thread:

> Page 8, appending static table
> ------------------------------
>
> Lacking documentation, I find it somewhat dubious that
> assigning higher indicies to the static tables very common
> entries makes sense performance wise.
>
> Forcing "GET" to have an index >30 causing it to encode into two
> bytes (or likely even three bytes) rather than one seems very
> counter inuitive.
>
> The dynmic and shifting indicies for the static table also robs
> high-performance load balancers an important optimization opportunity
> (ie: screening out non-GETs and similar).

Definitely agree with this one, also the need to copy static entries to the
dynamic table is also an issue here.   If there was interest in changing
hpack (say to support multiple state tables), then these should definitely
be reviewed - but probably not worth changing hpack just for these.

cheers



-- 
Greg Wilkins <gregw@intalio.com>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.