IETF Logo Mail Archive

RE: Comparing HTTP over QUIC header compression schemes

"Swindells, Thomas (Nokia - GB/Cambridge, UK)" <thomas.swindells@nokia.com> Tue, 06 June 2017 09:20 UTC

Return-Path: <thomas.swindells@nokia.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 8C404126DC2 for <quic@ietfa.amsl.com>; Tue, 6 Jun 2017 02:20:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.702
X-Spam-Level:
X-Spam-Status: No, score=-4.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 yVKXvc1PDKcK for <quic@ietfa.amsl.com>; Tue, 6 Jun 2017 02:20:21 -0700 (PDT)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0114.outbound.protection.outlook.com [104.47.1.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D527B12426E for <quic@ietf.org>; Tue, 6 Jun 2017 02:20:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=tzR+uF+t7gwb+5fiQQPGR9ORPqjcUBm3UOnkvl3rEbo=; b=LZ5GdN85jhR7/XXe/E41nE7s0GaV3SIBNYhloDn63vkUy3ZP1HWUaE9h/6g+BDsa80uFd7/uKf8xfE5eiD49tmIYLOX3jbsqMpefh/dFqUO3YAGV9P2q1U6MJYxQsEQzHNwH718KpI2EiY4bPUuB2OASv1K4h/wisKz8stV+hvg=
Received: from DB5PR07MB1237.eurprd07.prod.outlook.com (10.164.41.139) by DB5PR07MB1525.eurprd07.prod.outlook.com (10.165.212.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1157.9; Tue, 6 Jun 2017 09:20:17 +0000
Received: from DB5PR07MB1237.eurprd07.prod.outlook.com ([fe80::e14c:70a:c224:95c8]) by DB5PR07MB1237.eurprd07.prod.outlook.com ([fe80::e14c:70a:c224:95c8%14]) with mapi id 15.01.1157.010; Tue, 6 Jun 2017 09:20:17 +0000
From: "Swindells, Thomas (Nokia - GB/Cambridge, UK)" <thomas.swindells@nokia.com>
To: Martin Thomson <martin.thomson@gmail.com>, "Eggert, Lars" <lars@netapp.com>
CC: IETF QUIC WG <quic@ietf.org>, Alan Frindell <afrind@fb.com>
Subject: RE: Comparing HTTP over QUIC header compression schemes
Thread-Topic: Comparing HTTP over QUIC header compression schemes
Thread-Index: AQHS3pDkbL6XmOk6K0ms9bs9UuyP16IXiUoAgAADLQCAAACxQA==
Date: Tue, 06 Jun 2017 09:20:17 +0000
Message-ID: <DB5PR07MB1237A0C6B749D07472D48AFB84CB0@DB5PR07MB1237.eurprd07.prod.outlook.com>
References: <7241DB81-B9AD-44B6-9B03-902A8890F672@fb.com> <6C24B412-CB20-4DA4-9300-A1CA67CBC2A2@netapp.com> <CABkgnnU5Ar37eT83y5UXb-72r5qkUGpO164zKUM_1WuRv3vLvA@mail.gmail.com>
In-Reply-To: <CABkgnnU5Ar37eT83y5UXb-72r5qkUGpO164zKUM_1WuRv3vLvA@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=nokia.com;
x-originating-ip: [81.134.152.4]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DB5PR07MB1525; 7:74JQ3LNmaWaV5J96fct3F7GbbMf5jmaN1FI4Sucdmq6Bsfh3KW9Z5WBMjaG6gPNPtbBU57Sb62Jf5ODpZw8sIoV+rOOFkM0LgTaC4rN0lUX7bBCCPUX8XV0MJiR1XwJI+bXtuTKIcIzzKiVryqQiFT6NpnuN5i1ljlkE0qet7vSDwFyavujv5ILn1kT9UhS9gC63wsiuiNQdL2B23iONTFKamHEw69I93YdE9dCuFjCIQ3le2J7pNPVqaaKKxRP7bJg5KVDIxAFkGBSVND7P1mH7WtnNfFpvUxXVcRoc3qK8fqgOt+ReJbgLoHOsLPmggvjUvTKF52MKKbPQOb44Hg==
x-ms-traffictypediagnostic: DB5PR07MB1525:
x-ms-office365-filtering-correlation-id: e0a8fbd5-b69d-4b09-e522-08d4acbd3f60
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:DB5PR07MB1525;
x-microsoft-antispam-prvs: <DB5PR07MB1525D2015926EC08E660100984CB0@DB5PR07MB1525.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(67672495146484);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(20161123562025)(20161123558100)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB5PR07MB1525; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB5PR07MB1525;
x-forefront-prvs: 033054F29A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39400400002)(39850400002)(39410400002)(39860400002)(39840400002)(24454002)(13464003)(54356999)(53546009)(9686003)(2900100001)(25786009)(54906002)(966005)(39060400002)(14454004)(55016002)(99286003)(6306002)(4326008)(8936002)(3280700002)(86362001)(5660300001)(81166006)(478600001)(8676002)(2906002)(74316002)(3660700001)(66066001)(189998001)(5250100002)(305945005)(76176999)(347745004)(53936002)(7696004)(229853002)(50986999)(3846002)(2950100002)(102836003)(6116002)(16799955002)(7736002)(6506006)(33656002)(6436002)(38730400002)(6246003)(15188555004); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR07MB1525; H:DB5PR07MB1237.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jun 2017 09:20:17.7724 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR07MB1525
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/UbMtwSIuffhEKTSMZ63GdAG0pu8>
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:20:24 -0000

Two useful references I've found are the following:
http://www.ispreview.co.uk/index.php/2012/08/a-closer-look-at-latency-and-packet-loss-on-the-biggest-broadband-isps.html which covers UK ADSL and Fibre,
Page 44 of https://community.cablelabs.com/wiki/plugins/servlet/cablelabs/alfresco/download?id=3edb1609-17ff-4844-87ed-124314a73e7c which covers US cable markets.

The key summary from these:
ADSL: Typically less than 0.5%, though some providers seem to get much worse quality (up to 1.5%)
Fibre: Typically less than 0.3% but during congested periods may go higher -up to about 1%
Cable: Average was 0.000026529%, Very Worst case was 1.3%, 78.5% had 0 packet loss over 24 hours.

Obviously these are all market and technology dependent and are averages so there may be significant outliers.
Any more detailed references would be very useful in understanding this (and for FEC scheme proposals when the WG gets to that).

Thomas


> -----Original Message-----
> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Martin Thomson
> Sent: 06 June 2017 10:11
> To: Eggert, Lars <lars@netapp.com>
> Cc: IETF QUIC WG <quic@ietf.org>; Alan Frindell <afrind@fb.com>
> Subject: Re: Comparing HTTP over QUIC header compression schemes
> 
> 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.

v2.23.0 | Report a Bug | By Email