Re: Framing and control-frame continuations

HTTP/2 is a prioritized and muxxed protocol - therefore it needs a max
quanta small enough to still be responsive. As has been shown, 64KB max
size doesn't present an overhead burden, but it still represents 500ms of
serialization time on a 1mb/s network.. You could make a case that is too
much. 5mb/s is a pretty vanilla network these days and that's still 100ms
of transfer time. There is also the case of the server being able to
respond with alacrity to things like RST_STREAM in the face of unwanted
server pushes. These are cases where HTTP/2 has to work responsively.
Increasing bandwidth in the future makes it less important but the overhead
remains a constant fraction in those scenarios and doesn't, imo, create a
scaling burden.

I've worked with a number of spdy devs doing server side deployments that
make the frame size equal to the content length (assuming it fits in the
more generous spdy frame size) and have had the forseeable problems with
responsiveness. We can build a protocol that isn't susceptible to that, and
we should.


On Wed, Feb 6, 2013 at 11:19 PM, Poul-Henning Kamp <phk@phk.freebsd.dk>wrote:

> Content-Type: text/plain; charset=ISO-8859-1
> --------
> In message <
> CAP+FsNf1s3CV5eMzfmhFa2C8qf04uef732s690odE3uTcNTkGQ@mail.gmail.com>
> , Roberto Peon writes:
>
> >I know from past experience that one can fill up a 10GE pipe with very
> >small SPDY frames (1XXmillion 1 byte payloads)  when done correctly on
> >today's hardware, without using up all cores (though, to be fair it comes
> >close). This is pretty much a worst-case scenario.
>
> And where is the 10-20 years head-room in that ?
>
> Remember:  Cores are unlikely to become faster, you'll just get more
> and more of them.  Media on the other hand, seems to keep getting faster.
>
> >I've found that the amount of cores one uses to output a certain amount of
> >bandwidth is far more dependent on the the NIC kernel drivers and NIC
> >hardware than anything else.
>
> And you can take it from me, with my kernel-developer hat on, that
> it is an issue which is being worked on aggressively, so HTTP/2
> would be stupid to assume that the kernel guys don't improve this
> aspect.
>
> >I currently can't imagine what a 1T network architecture will look like
> >when going into a single machine.
>
> What you can or cannot imagine is not really a relevant yard-stick.
>
> And whats more, some of use don't need to imagine, I know people
> who _have_ (almost working) 1Tbit interfaces into a single machine
> now.
>
> There is absolutely no sane reason to limit HTTP/2 frames to a puny
> 64Kbyte at this time and date:  PDP-11 compatibility is not really
> an issue any more.
>
> --
> 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.
>
>