Re: #540: "jumbo" frames

On Wed, Jun 25, 2014 at 12:16 PM, Willy Tarreau <w@1wt.eu> wrote:

> You know, that's always the principle of cost of errors which multiplies
> by ten at each step towards the end user. Fixing a bug before compiling
> is cheaper than after, which is cheaper than after release which is cheaper
> than after it reaches customers, which is cheaper than once customers hit
> their own customers etc...
>

Understood. But given there are already rumblings about working on h3, why
not ship what we have experience with, and when we determine something to
have room for improvement, roll it into h3?


> Don't get me wrong, I don't want to dismiss anyone's work on the subject,
> but you also need to accept the fact that for some low level components
> like some intermediaries, implementing such a protocol is a tremendous
> work and that even the smallest changes can become a nightmare to adapt,
> so it is normal to observe a cool down period. To be clear, I *hope* to
> be able to implement end-to-end HTTP/2 in haproxy in one year, but I'm
> sure I'm dreaming...
>

Totally understood! I've spent the better part of the last year working on
this, so I know the amount of work involved :)


> Most of network operators and equipment providers disagree with you. On
> this page, Cisco claims that video already represents 66% of all the
> internet's IP traffic, and they even expect 79% for 2018 :
>
>
> http://www.cisco.com/c/en/us/solutions/service-provider/visual-networking-index-vni/index.html
>
> And you'll easily find a few others from Akamai and other CDNs citing
> similar numbers.
>

In terms of absolute byte count, sure, I won't argue that point (I may be
dumb, but I'm not THAT dumb). But for a regular web page (which my totally
unscientific gut feeling suggest there are still way more of those than
videos loaded in terms of number of resources),
http://httparchive.org/interesting.php#responsesizes indicates that (at
least for now), 16k is a reasonable size, as the average resource (except
flash... ugly, ugly flash) fits within 2 frames at most. (Please note, I'm
not trying to pull a "64 (or in this case 16) k is be enough for everyone"
thing, just pointing out some other current, relevant data.)

I absolutely agree, and we're precisely discussing the use case of the
> vast majority of the internet traffic which is not concerned by this
> case. OK we found how to finally make sites load fast, in large part
> thanks to the good research work made by the SPDY team. Now we're
> realizing that only *this* aspect was covered (and it was the most
> difficult one so that's normal) and that some of the design decisions
> made for this use case hurt the rest of the traffic and that it's not
> too late to fix this with the most minimal changes.
>
> I think it's the right approach to the problem to get the best in both
> use cases.
>

Fine, but again, let's make it an extension. That gives us the time and
flexibility to really determine which approach is best. You could even do
an A/B test on different jumbo frame layouts! If my users complain of slow
downloads or bad streaming video experience in the future, and the data
suggests I can fix that without adversely affecting normal page loads
(social networks, email, etc) by implementing a jumbo frame extension, then
I'll gladly do it. However, as it stands, my users are experiencing
suboptimal page load speeds right now, and I have a way to fix that. Ship
it.