Re: Comparing HTTP over QUIC header compression schemes

Patrick McManus <pmcmanus@mozilla.com> Tue, 06 June 2017 09:18 UTC

Return-Path: <pmcmanus@mozilla.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7DA71294C9 for <quic@ietfa.amsl.com>; Tue, 6 Jun 2017 02:18:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.735
X-Spam-Level:
X-Spam-Status: No, score=-0.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bA2AejFof59g for <quic@ietfa.amsl.com>; Tue, 6 Jun 2017 02:18:57 -0700 (PDT)
Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id BBE79126CB6 for <quic@ietf.org>; Tue, 6 Jun 2017 02:18:57 -0700 (PDT)
Received: from mail-qt0-f172.google.com (mail-qt0-f172.google.com [209.85.216.172]) by linode64.ducksong.com (Postfix) with ESMTPSA id 8EAB03A0A1 for <quic@ietf.org>; Tue, 6 Jun 2017 05:18:55 -0400 (EDT)
Received: by mail-qt0-f172.google.com with SMTP id u19so64323740qta.3 for <quic@ietf.org>; Tue, 06 Jun 2017 02:18:55 -0700 (PDT)
X-Gm-Message-State: AKS2vOyfIP+/FOO7tR3GcwcHbMVljKOVQ96zIBCYtYdKI889Pod1qMZC wDfDCChr4s8T1Bm99isVydzGtRhkfw==
X-Received: by 10.55.4.137 with SMTP id 131mr30261828qke.140.1496740735373; Tue, 06 Jun 2017 02:18:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.12.178.74 with HTTP; Tue, 6 Jun 2017 02:18:54 -0700 (PDT)
In-Reply-To: <CABkgnnU5Ar37eT83y5UXb-72r5qkUGpO164zKUM_1WuRv3vLvA@mail.gmail.com>
References: <7241DB81-B9AD-44B6-9B03-902A8890F672@fb.com> <6C24B412-CB20-4DA4-9300-A1CA67CBC2A2@netapp.com> <CABkgnnU5Ar37eT83y5UXb-72r5qkUGpO164zKUM_1WuRv3vLvA@mail.gmail.com>
From: Patrick McManus <pmcmanus@mozilla.com>
Date: Tue, 06 Jun 2017 11:18:54 +0200
X-Gmail-Original-Message-ID: <CAOdDvNpmAi+zGDm30c8AexU4C+8bQyHawjE9ZDY13G=ViTmp0g@mail.gmail.com>
Message-ID: <CAOdDvNpmAi+zGDm30c8AexU4C+8bQyHawjE9ZDY13G=ViTmp0g@mail.gmail.com>
Subject: Re: Comparing HTTP over QUIC header compression schemes
To: Martin Thomson <martin.thomson@gmail.com>
Cc: "Eggert, Lars" <lars@netapp.com>, IETF QUIC WG <quic@ietf.org>, Alan Frindell <afrind@fb.com>
Content-Type: multipart/alternative; boundary="001a1148c15cda5a380551471b3c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/FtuAo7XTsiptMmNMo-RsJLiENF4>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Jun 2017 09:19:00 -0000

Alan, I think this is really interesting. I want to reserve comment until I
can read it when not multipexing with a WG meeting :)

on the PLT: fastly generously shared some of their US based loss rates here
https://www.slideshare.net/Fastly/http2-what-no-one-is-telling-you (slide
102) .. which shows > 1.5% on roughly ~12% of connections. There are a
million caveats of course - but its one of the broader datapoints I've seen
and its awesome they shared operational information.

On Tue, Jun 6, 2017 at 11:10 AM, Martin Thomson <martin.thomson@gmail.com>
wrote:

> On 6 June 2017 at 10:59, Eggert, Lars <lars@netapp.com> wrote:
> > (2) simulating loss rates much above 1% is likely going to be pretty
> uninteresting, given that QUIC (and TCP, FWIW) have congestion controllers
> that will struggle to even deliver useful throughputs in these cases
>
>
> That's an interesting point.  I've seen a presentation (that I can't
> find now, but I can try) that shows that packet loss in real-world
> scenarios approaches 2% in a great many cases.
>
>