Re: Large Frame Proposal

On Mon, Jul 7, 2014 at 1:02 PM, Poul-Henning Kamp <phk@phk.freebsd.dk>
wrote:

> In message <CAEn92To91LMwMzRubur5mWLfAc=
> f+XZhS0uLFSdQh-Z-7ceo6A@mail.gmail.com>
> , Johnny Graettinger writes:
>
> >The problem with doing so is that it precludes the possibility
> >of streaming HPACK.
>
> While it may be an advantage (how big ?) for a client to be able to
> "stream HPACK" it is a major inconvenience to everybody else in the
> HTTP network topology to have no idea how much data is incoming.
>

By data you're talking about the size of the compressed headers.
You're basing that argument about the amount of inconvenience on the
assertion that one achieves higher efficiency by allocating memory based on
what a possibly malicious client says should be the size.
I'm certain that you're right that it would be more efficient, until
attacked.

If we're following this argument to its logical conclusion, however, we
should also be communicating the *uncompressed* size, since we currently
have no idea how large we should be allocating buffers for that, and
arguably that is where the larger variance in amount of memory
consumed/buffer allocated would be.


> Given that the CPU/MEM performance bottleneck is everywhere but the
> client there needs to be really good arguments for shifting the
> inconvenience of finding the total length from client to everybody
> else.
>
>
There is also the latency tradeoff, which for many usecases is the big
deal, and keeps being ignored.
Additionally, there is the DoS consideration, as mentioned before.
Since proxies are clients, and often even more constrained than servers,
requirements to buffer are potentially onerous, especially given that one
is not required to do this for HTTP today.


> Where are these arguments ?  I cannot find them.
>
> It seems like "streaming HPACK" is an merely a neat idea and I have
> certainly not seen any examples of clients that cannot function
> without it ?
>

The same can be said of jumbo frames, etc.

-=R


>
> Poul-Henning
>
> PS: In a previous email I outlined several strategies tiny clients could
> use, I won't repeat them here.
>
> --
> 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.
>
>