IETF Logo Mail Archive

Re: Comparing HTTP over QUIC header compression schemes

Ian Swett <ianswett@google.com> Wed, 07 June 2017 07:59 UTC

Return-Path: <ianswett@google.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 ABF4B12EAF5 for <quic@ietfa.amsl.com>; Wed, 7 Jun 2017 00:59:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 vlU4KS8Z3Bx0 for <quic@ietfa.amsl.com>; Wed, 7 Jun 2017 00:59:49 -0700 (PDT)
Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 535C3126CBF for <quic@ietf.org>; Wed, 7 Jun 2017 00:59:49 -0700 (PDT)
Received: by mail-yw0-x22b.google.com with SMTP id l14so1586941ywk.1 for <quic@ietf.org>; Wed, 07 Jun 2017 00:59:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=h0OM9IHucraFrPfKsRXybLSIZSc+Zu6weQD+ANBh7QI=; b=JPRt850hNDJU0aOh/YC+t7QZsgAq5m5HzxeIfEv8iQsimjMS3cueZ2w13p3U8HU+0T 8WtSlEWVFVwBt4L1X/kdUn01TA48hOzZcE7buVwCXUejVzO0SUgFIBoPuPO2CILgqv8E dulA0R+rxtz5yTODqCxUreon6+6HpORoYRi0Oel1yI/luZEk5fjrg/hVl1tvSsQkNAQr WBKRFQF5lZNYJyOZDaMRBlIbGN9Em8oJJcpZn26IzXIQVJ8IfLtSej7mePugkuZ3doKW 8/h4wzD1tVO2PYB1vdoUDUVBSxqtVKjy4uAG3rpuvazYk0fZCddwPKepT4I1PzJ/iwfG hggg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=h0OM9IHucraFrPfKsRXybLSIZSc+Zu6weQD+ANBh7QI=; b=a26zOOOs7dz6AkEkIrDlMDKvvG0oMUuU38orbEKbLxD+lDYRgLG1bgvWnEhymrV6Km buVMek8ucFwFCKnE5WGrTUD+n0ZXAwFU0JW95uWKt0TAu8ljhvwcJLbbhICPZVHfLERC MZGSNuMxmkl4T5Hbd7pOimuTQutSCPj33im+ZqayyhnednV32e/+5fc9uxcv0AbQXd+W QeQ7A1SdcuqpSZSl+t3F8mkcgl9AxUgLj68r4jb0EbJwzsDXn0/MzQlDJUrU1O5rj8Tw JgtBvLarXzHTr/vF7toMqGe4y7J1Zs2JMZwk0nwWkyhqMRfBBTCzoZ2xg9CeJKAbJrGT /FXA==
X-Gm-Message-State: AODbwcCYLuYPmiJUNdVCtbvbrDwFnFszf7kti44UO15VqmIi7SEb+1/T vE1YZQACFVq6R01+mFFhFC9pILgUEk++
X-Received: by 10.13.214.87 with SMTP id y84mr5797588ywd.303.1496822388433; Wed, 07 Jun 2017 00:59:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.204.134 with HTTP; Wed, 7 Jun 2017 00:59:27 -0700 (PDT)
In-Reply-To: <BF99D17D-766F-4500-A845-E57EA50828B0@fb.com>
References: <7241DB81-B9AD-44B6-9B03-902A8890F672@fb.com> <6C24B412-CB20-4DA4-9300-A1CA67CBC2A2@netapp.com> <CAAZdMacbaGJ7yVj956UmzvqhFDbn9zR8UxvkqMMs1U-jaCkxtg@mail.gmail.com> <BF99D17D-766F-4500-A845-E57EA50828B0@fb.com>
From: Ian Swett <ianswett@google.com>
Date: Wed, 07 Jun 2017 03:59:27 -0400
Message-ID: <CAKcm_gOt9nrP_+Ha09X=+Zv+T8bWb4w_L+a4G0AjAQz3TcAJbQ@mail.gmail.com>
Subject: Re: Comparing HTTP over QUIC header compression schemes
To: Alan Frindell <afrind@fb.com>
Cc: IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="001a114fa5cac1b02305515a1e2d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/smNP1Zae-kkuymF0U5Ln7haQw3I>
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: Wed, 07 Jun 2017 07:59:50 -0000

Thanks for doing this analysis!  Two questions:

1) Is it possible to simulate how this impacts page load time for your
simulated workload?
2) How do the results change if you extend the simulation to 20% loss?  As
Victor noted, 20%+ loss is not that uncommon on public networks.

On Wed, Jun 7, 2017 at 2:40 AM, Alan Frindell <afrind@fb.com> wrote:

> Thanks for the initial feedback everyone.  For anyone in Paris that wants
> to discuss QPACK versus QCRAM in more detail, Mike, Buck and I will be
> talking over lunch today.
>
>
>
> -Alan
>
>
>
> *From: *Victor Vasiliev <vasilvv@google.com>
> *Date: *Tuesday, June 6, 2017 at 11:56 AM
> *To: *"Eggert, Lars" <lars@netapp.com>
> *Cc: *Alan Frindell <afrind@fb.com>, IETF QUIC WG <quic@ietf.org>
> *Subject: *Re: Comparing HTTP over QUIC header compression schemes
>
>
>
> On Tue, Jun 6, 2017 at 4:59 AM, 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
>
>
>
> On networks with traffic policers, loss rates are usually 20% or higher
> (Flach et al, "An Internet-Wide Analysis of Traffic Policing", SIGCOMM
> 2016). This normally does not work well with TCP congestion control, but
> some of the more recent work (like TCP BBR) tries to address that.
>
>
>
>   -- Victor.
>

v2.23.0 | Report a Bug | By Email