Re: SPDY Header Frames

The max theoretical compression with a perfect deflate implementation is
1024 to one, according to documentation.
Thankfully, the zlib reference implementation allows stream decompression
and thus allows you to specify the max amount of bytes one allows the
incoming stream to inflate into. In other words, memory usage is bounded
and you can reject stuff that is overly large before it causes any problems.

I'm not particularly enamored of the deflate stuff as a whole solution. I
think it is just part of a whole solution in a solution space than needs
more exploration.
I'll be putting something out about this shortly, actually... just have to
stop responding here so I have time to finish writing it up (and then get
to work simulating and experimenting)!

-=R
On Jul 17, 2012 12:28 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.
>
> >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).
>
> 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.
>
> 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.
>
>