Re: HTTP 2.0 and a Faster, more Mobile-friendly web

[Jonathan Ballard <[e-mail]>]

Where that is all cold there is the medium expiration in the mentioned
common suite: chrome://chrome/settings/content/expiration/medium?true.

SPDY+TLS offers no immediate exception except recompile resources to local
storage, and all of that is said off-topic at Vancouver on or about USB.

On Monday, July 30, 2012, Jitu Padhye wrote:

>  **Ø  **Was the client/server speaking SPDY/2 or SPDY/3?****
>
>       Spdy/2****
>
> ** **
>
> **Ø  **A percentage of the time, Chrome will not use SPDY (it decides
> this at startup). Did you verify that it was always speaking SPDY? (I'd
> guess yes!)****
>
> Yes. ****
>
> ** **
>
> **Ø  **Was the server using the CWND set sent in the SETTINGS frame, and
> was it sending it to the client?****
>
> I did not check this – I will go back and look. ** **
>
> ** **
>
> **Ø  **What was the server's initcwnd?****
>
> Whatever the default is. I think it was 2 or 4. I will take a look. ****
>
> ** **
>
> **Ø  **Was slow-start-after-idle turned off on the kernel?****
>
> No. Again, we only used default settings. ****
>
> ** **
>
> **Ø  **How long were the various connections in slow start, and did they
> ever exit slow-start?****
>
> I will have to take a look. ****
>
> ** **
>
> **Ø  **Was the SSL cert chain the same size and using the same algorithms?
> ****
>
> Yes. ****
>
> ** **
>
> **Ø  **Was the dummynet (or equivalent) configured to have appropriate
> buffer size (else it does packet drops silently)?****
>
> Yes, and I know this, because I had initially screwed this up J****
>
> ** **
>
> **Ø  **Were these all cold-connection, cold-cache first-page load
> timings? The use of keep-alive in figure 3 would seem to indicate
> otherwise, but I'm not sure which are which...****
>
> All cold cache. Keep alive is for only fetches while loading the first
> page. ****
>
> ** **
>
> **Ø  **Did you put Chromium into 'replay' mode (where date and random
> always return in the same manner, regardless of actual date)?****
>
> No, but I agree that this setting would have made more sense. ****
>
> ** **
>
> **Ø  **Any particular reason that you turned off entity-body compression
> in Apache? Were the resources saved verbatim from WinHTTrack (in which case
> it'd make sense)?****
>
> Not quite sure what you are asking here … can you please clarify?****
>
> ** **
>
> **Ø  **Was the server emulating the original server's think times? This
> can have a very, very large impact on pipelined HTTP performance. ****
>
>       Only “index.html” was loaded for each site. I should clarify that in
> text. So think times are not an issue. ****
>
> ** **
>
> **Ø  **We've found that the various automatic page-is-done signals are
> often less useful than something which measures the above-the-fold page
> load time. This generally involves cameras pointed at screens and a human
> looking at the video to determine at which frame the page is useful, and
> designating that frame as 'done-for-above-the-fold'****
>
> I agree that age load time, as we measured it, is not a foolproof metric.
> The problem is that all other alternatives are too cumbersome to measure
> (and worse) replicate correctly. ****
>
> ** **
>
> **Ø  **I'd love to see if we could get a common suite of test data over
> which we could all run experiments/benchmarks. Is anyone else interested in
> doing so?****
>
> This is definitely interesting. Something like RFC5033?****
>
> ** **
>
> ** **
>
> *From:* Roberto Peon [mailto:[e-mail] <javascript:_e({}, 'cvml',
> '[e-mail]');>]
> *Sent:* Sunday, July 29, 2012 3:16 PM
> *To:* Henrik Frystyk Nielsen
> *Cc:* [e-mail] <javascript:_e({}, 'cvml',
> '[e-mail]');>; Gabriel Montenegro; Rob Trace; Adalberto
> Foresti (MS OPEN TECH)
> *Subject:* Re: HTTP 2.0 and a Faster, more Mobile-friendly web****
>
> ** **
>
> ** **
>
> Interesting data! Questions about test methodology:****
>
> ** **
>
> Was the client/server speaking SPDY/2 or SPDY/3?****
>
> A percentage of the time, Chrome will not use SPDY (it decides this at
> startup). Did you verify that it was always speaking SPDY? (I'd guess yes!)
> ****
>
> Was the server using the CWND set sent in the SETTINGS frame, and was it
> sending it to the client?****
>
> What was the server's initcwnd?****
>
> Was slow-start-after-idle turned off on the kernel?****
>
> How long were the various connections in slow start, and did they ever
> exit slow-start?****
>
> Was the SSL cert chain the same size and using the same algorithms?****
>
> Was the dummynet (or equivalent) configured to have appropriate buffer
> size (else it does packet drops silently)?****
>
> Were these all cold-connection, cold-cache first-page load timings? The
> use of keep-alive in figure 3 would seem to indicate otherwise, but I'm not
> sure which are which...****
>
> Did you put Chromium into 'replay' mode (where date and random always
> return in the same manner, regardless of actual date)?****
>
> Any particular reason that you turned off entity-body compression in
> Apache? Were the resources saved verbatim from WinHTTrack (in which case
> it'd make sense)?****
>
> Was the server emulating the original server's think times? This can have
> a very, very large impact on pipelined HTTP performance. ****
>
> ** **
>
> We've found that the various automatic page-is-done signals are often less
> useful than something which measures the above-the-fold page load time.
> This generally involves cameras pointed at screens and a human looking at
> the video to determine at which frame the page is useful, and designating
> that frame as 'done-for-above-the-fold'****
>
> ** **
>
> I'd love to see if we could get a common suite of test data over which we
> could all run experiments/benchmarks.****
>
> Is anyone else interested in doing so?****
>
> ** **
>
> -=R****
>
> On Sun, Jul 29, 2012 at 1:14 PM, Henrik Frystyk Nielsen <
> [e-mail]> wrote:****
>
> Dear All,****
>
>  ****
>
> We remain committed to the HTTP/2.0 standards process and look forward to
> seeing many of you this week at the IETF meeting in Vancouver to continue
> the discussion.  In the spirit of open discussion, we wanted to share some
> observations in advance of the meeting and share the latest progress from
> prototyping and testing. ****
>
>  ****
>
> There are currently three different proposals that the group is working
> through:****
>
>  ****
>
>    * SPDY (http://tools.ietf.org/html/draft-mbelshe-httpbis-spdy),****
>
>    * HTTP Speed+Mobility (
> http://tools.ietf.org/html/draft-montenegro-httpbis-speed-mobility),****
>
>    * Network-Friendly HTTP Upgrade (
> http://tools.ietf.org/html/draft-tarreau-httpbis-network-friendly). ****
>
>  ****
>
> The good news is that everyone involved wants to make the Web faster, more
> scalable, more secure, and more mobile-friendly, and each proposal has
> benefits in different areas that the discussion can choose from.****
>
>  ****
>
> --- A Genuinely Faster Web ---****
>
>  ****
>
> The SPDY proposal has been great for raising awareness of Web performance.
> It takes a “clean slate” approach to improving HTTP.****
>
>  ****
>
> To compare the performance of SPDY with HTTP/1.1 we have run tests
> comparing download times of several public web sites using a controlled
> tested study. The test uses publically available software run with mostly
> default configurations while applying all the currently available
> optimizations to HTTP/1.1. You can find a prelim
>