Re: Reference set in HPACK

[Roberto Peon <[e-mail]>]

On Wed, Jul 2, 2014 at 12:22 AM, Poul-Henning Kamp <[e-mail]>
wrote:

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


Your analysis seems a bit flawed.

>From the server side, server push is most likely to be used during
slowstart, and during the time that the initial resource (e.g. the HTML)
would be sent.
Inlining is the technique most often used to reduce the number of request.
It is a strategy that works well most of the time for cold pageloads, but
it also harms latency for subsequent navigations deeper into the site as
those resources cannot be cached.
For server push to be effective, it should not take significantly more time
than inlining. Its primary benefit ends up being to navigations after the
first cold page load, though it can also remove a single RT from a cold
page load assuming the window opens enough to allow that (which is not
certain).
When server push becomes adopted better (there is a chicken and egg issue
now which is hopefully being addressed), sites change how they present
resources to HTTP2 connections, and the number of resources for a page
seems likely to increase as folks get to abandon inlining, spriteing, etc.

For a client which is creating a new connection, e.g. on a browser restart,
it may have a great many requests to send. I often have 20 or more tabs
open, for instance. In cases such as these there are a fair number of
requests which will look more similar and which should be sent in the first
few packets.
-=R



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