Re: SPDY Header Frames

On Tue, Jul 17, 2012 at 12:27 AM, Poul-Henning Kamp <phk@phk.freebsd.dk>wrote:

> In message <CABP7RbdZPYYqtDFWUprrAmGQ8GehOTh-LvXq9gizXGUJg4=
> 68g@mail.gmail.com>
> , James M Snell writes:
>
> >3. Values may be binary or character based, as indicated by a flags field.
> >Values may be up to max(int32) in length.
>
> Allowing such large fields is counterproductive in my opinion.
>
> No implementation can have a limit that large without becoming
> a sitting duck for DoS attacks.
>
> It would be far better to put a realistic, but still generous size
> restriction.  Not sure if 16 bits is always enough, but the advantage
> will likely outweigh any disadvantages.
>

i tend to agree but I think we need to test out a variety of scenarios
before we limit too much. Instinct tells me that 16-bits is likely going to
be more than enough.


>
> >The entire header block is encoded into a structure of 145 bytes in
> length;
> >
> [...]
> >
> >By comparison, the same structure encoded using the existing SPDY HEADER
> >block would require 208 bytes sans compression.
> >
> >After applying compression of the block using the SPDY dictionary, the
> >block compresses into 6 compact bytes.
> >
> >[120, 63, -29, -58, -89, -62]
>
> This is where I think we should be careful about what we measure
> and optimize for.
>
> Those six bytes will take a lot more CPU effort to unpack than
> your 145 bytes (I think your proposed encoding is quite bloated
> btw, but that's not an argument I need to carry for this point).
>
>
Yeah.. um.. ignore that compression ratio, lol... that was an oopsie on my
part. The actual value is 128-bytes compressed using the SPDY dictionary
and optimizing for size. And yes, looking at the ratio (the..um.. real
one), i'm not convinced that the compression is completely worth the
additional cost. As the SPDY spec itself acknowledges, it is counter
productive to compress already compressed data; so if our header encoding
is compact enough without it, why spend the additional cycles to save 20
bytes or so.

I am interested in hearing what further optimizations could be made to the
structure. At this point I would definitely hesitate to call this a
"proposal" in the formal sense. It's an exercise to experiment with
alternative header encodings to see what benefits we can reap, if any. If
the exercise proves valuable and bears fruit, I'll draft up a proposal.


> The really important metric is that most requests fit in a single
> MTU.  Inside that limit, expending bytes to gain parsing speed can
> be both a good and necessary (for HTTP-routers) tradeoff.
>
> In that view, the difference between six and 208 bytes is not
> terribly significant on its own, whereas a difference between
> 1400 and 1602 bytes would be.
>
> The main and almost only reason requests don't fit in one MTU is
> cookies, with a minor side-order of URI and User-Agent,
> so if we can design away the need for cookies, we (almost)
> don't need the computational complexity of deflate.
>

I'm all for eliminating or reducing the use of cookies. A Session header is
an excellent suggestion, IMHO, and something that reasonably should have
been done a long time ago. The more I look at it (assuming just for the
sake of discussion we're using SPDY)... the more I want to limit the number
of HTTP Request headers we drop into SYN_STREAM. SYN_STREAM should be kept
minimal, consisting of the version, method, host, request-uri and session.
All additional request headers can be pushed into one or more HEADER frames
following the SYN_STREAM and sized so that things easily fit into one MTU.

- James


>
> And there is another aspect which has me very worried about
> deflate at this point in the protocol:  Has anybody tried
> to see how big a deflate output they can produce with
> a single MTU of input ?
>
> My guestimate is well north of a 1MB.
>
> That's a lot of DoS leverage for a single packet.
>
> --
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk@FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
>