Re: #541: CONTINUATION

In message <2B18DFA2-9B08-426C-B585-C142F2DFD5E7@mnot.net>, Mark Nottingham wri
tes:

>I've heard it argued that CONTINUATION on smaller-than-16k chunks is 
>useful, because it allows you to flush your buffers on sending. However, 
>in the current design, it seems like that's pushing a problem off of 
>the sender and onto the recipient, which isn't a great dynamic. 

In the HTTP ecosystem the choking point(s) are everywhere but on
the client side:  proxies, load-balancers and servers all cope with
far higher traffic-densities than clients do.

There may be exceptions such as CERNS LHC TB/s data distribution,
but I bet they will not have trouble buffering a few kilobytes of
headers before sending them :-)

I think it is perfectly fair to demand that clients be able to
*send* the HEADERS in one go, because there are plenty of avenues
for them to do so, even in very small-memory environments.

Very puny environments may be able to predict or even hardcode
the HEADERS length -- after all there are only so many different
things the microcontroller in a light-bulb can tell the world.

If that doesn't work for you, you can structure you web-application
to put the variable stuff into the DATA frames.

Finally, by suitably choosing how to use HPACK compression, you
can do a two-pass algorithm and just calculate the HEADERS length
on the first pass, and send the HEADERS on the second pass, using
as many writes as you like.  If you are that memory constrained
there will be no other competing frames sent at the same time.

>This drops us back into the jumbo argument. Allowing large DATA frames 
>defeats the goals of multiplexing, [...]

When I tried to learn to play the violin, the first thing my teacher
said was "It's unfair:  You have to pay for the entire bow, but you
only get to use a little bit of it."

Just because you *can* send jumboframes doesn't mean you *have* to
do so.

The one exception I want is that you SHALL send all the headers in one
single frame.

The size of those headers is a web-app design issue, and if sending
around 40K of cookies hurts example.com's performance and
user-perception, then example.com's web-designers are perfectly
aware both what and how to fix that problem.

-- 
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.

Received on Friday, 4 July 2014 07:57:44 UTC