Re: Reference set in HPACK

["Poul-Henning Kamp" <[e-mail]>]

In message <CAP+FsNf=[e-mail]>, Roberto Peon writes:
>--047d7b2e50c07345ea04fd30267d

>That is orthogonal-- small data frames are necessary for latency as well,

I don't dispute that, I just dispute the value chosen for "small".

But back to your two saved packets:

I just tried loading a typical well engineered major news site over
HTTP/1 and captured a tcpdump.

A total of 1891906 bytes were sent in the TCP packets and 146 HTTP
transactions performed.

1718723 of those byes are accounted for by Content-Length (there
is a single chunked object but I can't be bothered to tally it from
the tcpdump).

If the 1718723 bytes optimistically had been sent on a single TCP
in one direction from a single server, that would take 1193 packets
(without HTTP/2 overhead of framing).

Your proposed saving of 2 packets can therefore never exceed a
0.17% ratio for this particular case.

In practice 15 different servers were involved and just the
distribution of content over 15 TCP connections alone adds
7.5 packets on average in "rounding error", in addition to
the three-way handshakes and so on.

It also reduces the chances of the few bytes shaved by the reference
set from saving any packets (as opposed to having a few byts
less in a packet).

If I remeber my statistics right, your already pretty slim chances
of shaving a packet is reduced by sqrt(15), since the reference
set doesn't do anything for you cross-site.

So provided the byte for byte savings previously quoted are correct
on average you'd probably save half a packet out of the total 1200.

That is 0.04 %.

Unless you have actual non-contrived data that shows a remarkably
better outcome than that, the reference set is not worth the added
complexity.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[e-mail]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.