Current QUIC performance is compromised compared to TCP for asymmetric paths
Gorry Fairhurst <gorry@erg.abdn.ac.uk> Mon, 20 April 2020 12:59 UTC
Return-Path: <gorry@erg.abdn.ac.uk>
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 7B6283A0C69 for <quic@ietfa.amsl.com>; Mon, 20 Apr 2020 05:59:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.012
X-Spam-Level:
X-Spam-Status: No, score=0.012 tagged_above=-999 required=5 tests=[SPF_NONE=0.001, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham 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 1u7otETGrE8M for <quic@ietfa.amsl.com>; Mon, 20 Apr 2020 05:59:20 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7143A0C67 for <quic@ietf.org>; Mon, 20 Apr 2020 05:59:20 -0700 (PDT)
Received: from GF-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id BB00E1B00127 for <quic@ietf.org>; Mon, 20 Apr 2020 13:59:17 +0100 (BST)
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Subject: Current QUIC performance is compromised compared to TCP for asymmetric paths
To: QUIC WG <quic@ietf.org>
Message-ID: <6eda22ea-7cfe-b6ad-b250-cd6943afa7aa@erg.abdn.ac.uk>
Date: Mon, 20 Apr 2020 13:59:17 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/NZBbuY88v0lrVspQE2A5br83asA>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 20 Apr 2020 12:59:26 -0000
We had prepared some slides for the Vancouver IETD to discuss QUIC's ACKs, and how to make QUIC work better than TCP in common asymmetric paths. This is a short slide deck that summarises what we have learned about ACKs in QUIC: https://erg.abdn.ac.uk/users/gorry/ietf/QUIC/ It compares the ACK traffic of TCP with that of QUIC from the point of view of a path where QUIC's return traffic is somehow constrained or could impact other user traffic. We think that ACKs are a concern for various shared capacity return link (e.g., radio-based methods in WiFi or mobile cellular were ACKs consume spectrum/radio resource or battery; shared capacity satellite broadband return link or the uplink of a cable system). For TCP, such systems commonly involve a PEP or an ACK Filtering mechanism (which clearly isn't wanted or even possible for QUIC). The baseline QUIC performance (as per current spec) suffers over these paths. So our first question is: Do other people think it is important that the default specified for QUIC works well with asymmetric paths ? Gorry
- Current QUIC performance is compromised compared … Gorry Fairhurst
- RE: Current QUIC performance is compromised compa… Border, John
- RE: Current QUIC performance is compromised compa… Rahul Arvind Jadhav
- Re: Current QUIC performance is compromised compa… Gorry Fairhurst
- Re: Current QUIC performance is compromised compa… Lars Eggert