Re: Comparing HTTP over QUIC header compression schemes

Victor Vasiliev <vasilvv@google.com> Tue, 06 June 2017 09:56 UTC

Return-Path: <vasilvv@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 14759128B44 for <quic@ietfa.amsl.com>; Tue, 6 Jun 2017 02:56:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 idcB5cHXr6Lg for <quic@ietfa.amsl.com>; Tue, 6 Jun 2017 02:56:53 -0700 (PDT)
Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (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 9A026129BF8 for <quic@ietf.org>; Tue, 6 Jun 2017 02:56:53 -0700 (PDT)
Received: by mail-qt0-x22a.google.com with SMTP id u19so65173226qta.3 for <quic@ietf.org>; Tue, 06 Jun 2017 02:56:53 -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=/chcCftwt2kZupeObTPxCsRm3dCk9QCZB25fQ2ZcTBo=; b=BTD7m5Qu0grXX7VrO/0bCYkuhZ27jJ1kGnI8N11Q1MSuITi62/2LNTnFNBLlRJETt4 ZFItP25Y526xQMAAQ2bueKjKo63xp5N9q2KmDXoAWY6g8J8d1XtRAxsukP2a1s5hQGWD YPJYJOrxXxURDF1IgY8cXR6sUv2HW1o/THfSBNpXnmzOfmeRQruV6YRgy0oLAUYGWOov Ossq2B0pfUqTl8k4Lnm8jYEIbBl3/BfbkWKpxU1F+pg5nHvOXRThKAB7xbexaIkZ/k7W zqOEycCG4zVCxD9NxagSi/10xkKR4zyy2DrY1xWRO8an7IO3wxFHfv7f52qyomRHSib2 JeKA==
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=/chcCftwt2kZupeObTPxCsRm3dCk9QCZB25fQ2ZcTBo=; b=FM89ZRsj1TBw5q8TUCv4qBJo7AlIVK6VfaMpPh/Cet0fchW+wWorqyyI41O80m43Ii 9lyJEE+G023qFjSxmszZLLX+ANnaBcHBOd94l3qKv4vvUXrujdamLtue0yVtCuXa5aw4 wjE7UMITgFbr/4uxetWD3CZoHUZJYfBCpDL9ABuP7JNlfHk/pyurlJw8T+cccdMHovKK jQVicTvchb6AqsSulk9J7iXmpl5GcX7BvIDAKDzCShqO+x/rCLPtP9heF44VWzvRENMg ibhj8elUY4DzhPQzdbhWaAlR50DgXU1m/IgaxFX++bIm+13gEoMoIYrFLzDmrCsz8ZwE NRBw==
X-Gm-Message-State: AKS2vOyOw8WOXbc3udhkABgyHMVJsS6csdPPSedwmDKxGdEPGKP2MXa5 HA6UUrGdHAkNry/aub+jsTCXhKfCBH1k
X-Received: by 10.55.175.67 with SMTP id y64mr30277096qke.130.1496743012589; Tue, 06 Jun 2017 02:56:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.46.65 with HTTP; Tue, 6 Jun 2017 02:56:51 -0700 (PDT)
In-Reply-To: <6C24B412-CB20-4DA4-9300-A1CA67CBC2A2@netapp.com>
References: <7241DB81-B9AD-44B6-9B03-902A8890F672@fb.com> <6C24B412-CB20-4DA4-9300-A1CA67CBC2A2@netapp.com>
From: Victor Vasiliev <vasilvv@google.com>
Date: Tue, 06 Jun 2017 05:56:51 -0400
Message-ID: <CAAZdMacbaGJ7yVj956UmzvqhFDbn9zR8UxvkqMMs1U-jaCkxtg@mail.gmail.com>
Subject: Re: Comparing HTTP over QUIC header compression schemes
To: "Eggert, Lars" <lars@netapp.com>
Cc: Alan Frindell <afrind@fb.com>, IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c070136967730055147a368"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/OeHm2G0oobFGfdO5t3t8ZgZzL7s>
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:56:55 -0000

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.