Re: New Version Notification for draft-bonaventure-quic-atsss-overview-00.txt

Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be> Wed, 03 June 2020 06:31 UTC

Return-Path: <olivier.bonaventure@uclouvain.be>
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 C7D863A07B3 for <quic@ietfa.amsl.com>; Tue, 2 Jun 2020 23:31:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uclouvain.be
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 oh9a8qTM9Fsz for <quic@ietfa.amsl.com>; Tue, 2 Jun 2020 23:31:34 -0700 (PDT)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10104.outbound.protection.outlook.com [40.107.1.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 305553A07A5 for <quic@ietf.org>; Tue, 2 Jun 2020 23:31:33 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hEGnQX1EuxN3/VQBhGwwfo7rz0kBYlPn1FgqXbdbxIOojL2yLlsT6vNShpD6aMogDT7pNe+kBkLVq9UnMBCwyVjJPpHaf8SX9XgEVAkUjP3Lf4bhm9fgROG7ic7kR2KXx+7cBuS1YTLW4zunTwVeK2/FJcKdQEAtBuGg0Z3Vj9xafEp+xR/L4IFdPU0AcllW3ZVTpvx9r1mQg7biznn2UGRrqQBPlrADY02ePGDHwSHDUUfSr1jkyyO0RDdWXGqM3p1gSVJJTOWX8tGat1AWMJRKAJN4n3LCc4XjOjZOo5TLyWWtL8jpXnfW4fsR0RHCY0fzW5/yBifAfxaB72qo6A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nE7x+kBxs1Gs8ptg45tnfhjMhhOqaOqZNBONYo8ZLCI=; b=Z/IAkMETfvo1fiySSku93swMbTMBY3m4GSAKsjlZf9fg7C4pfU9SaFVUh27VhiIRiQ/tIX4pRmMphACwoaJ5xd3ZnslxsJrpkoOc8KCxRSMdR4AaX5IL9IU/tabppLXBvWvd83CCrJJHB1geGP3yItBhqa9oByayFECb8G2c/JicU0htx/sjoWXGdt7BVZdnnoflQdtGH8iAo3BrOKFTip+dnt9jnZFsKjyQOekg2+vPbOc5R7eZgyj8ADMlkmoQRzog026gTrZCHck1wFjgTvuYWN4rxej4GkghkXL48DdbMVaP++/ARKbQ5JKcvmIKOLrVTFvnGscXvkBdqKNOrg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uclouvain.be; dmarc=pass action=none header.from=uclouvain.be; dkim=pass header.d=uclouvain.be; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uclouvain.be; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nE7x+kBxs1Gs8ptg45tnfhjMhhOqaOqZNBONYo8ZLCI=; b=PrZImo39Oh49gBVxUZGsYcJA7OQGbdnQIU+QH9XAyoPTiWkUvGtupssRszSd7JuQJIJHMPDgSYSWxYua5OvmoGH2y2Dxka+B/9WON21UeEhT7Sde5OGsvSi4sBVEmLBcLDoRDp9gc+F6OphpsdcHN38PrKe0K4VGgAyVoxrOaFM=
Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=uclouvain.be;
Received: from AM7PR03MB6642.eurprd03.prod.outlook.com (2603:10a6:20b:1bf::6) by AM7PR03MB6546.eurprd03.prod.outlook.com (2603:10a6:20b:1bf::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3045.19; Wed, 3 Jun 2020 06:31:29 +0000
Received: from AM7PR03MB6642.eurprd03.prod.outlook.com ([fe80::fcc2:e19d:eec3:15e6]) by AM7PR03MB6642.eurprd03.prod.outlook.com ([fe80::fcc2:e19d:eec3:15e6%7]) with mapi id 15.20.3066.018; Wed, 3 Jun 2020 06:31:29 +0000
Reply-To: Olivier.Bonaventure@uclouvain.be
Subject: Re: New Version Notification for draft-bonaventure-quic-atsss-overview-00.txt
To: Matt Joras <matt.joras@gmail.com>, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Cc: IETF QUIC WG <quic@ietf.org>
References: <159084638843.27466.7915766554130545967@ietfa.amsl.com> <CAKKJt-eHQtgjc-zuO7vrGZ1Q2c7=3hetOb0FyqnEmbTDu1Uwuw@mail.gmail.com> <CADdTf+iBRLu20OH-WTEmo=e7WZ8Ce5QVP+_LWO09u6LxjCPe2g@mail.gmail.com>
From: Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be>
Message-ID: <0ecd2f86-3472-5242-eb41-6eaefb640027@uclouvain.be>
Date: Wed, 3 Jun 2020 08:31:28 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.8.1
In-Reply-To: <CADdTf+iBRLu20OH-WTEmo=e7WZ8Ce5QVP+_LWO09u6LxjCPe2g@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: fr-classic
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: AM4PR0902CA0016.eurprd09.prod.outlook.com (2603:10a6:200:9b::26) To AM7PR03MB6642.eurprd03.prod.outlook.com (2603:10a6:20b:1bf::6)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from mbpobo-2.local (2a02:2788:484:b4f:85fe:72b8:b48d:9955) by AM4PR0902CA0016.eurprd09.prod.outlook.com (2603:10a6:200:9b::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18 via Frontend Transport; Wed, 3 Jun 2020 06:31:29 +0000
X-Originating-IP: [2a02:2788:484:b4f:85fe:72b8:b48d:9955]
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 37157a23-0d89-481d-d739-08d80787bfd4
X-MS-TrafficTypeDiagnostic: AM7PR03MB6546:
X-Microsoft-Antispam-PRVS: <AM7PR03MB6546D4D46B91419936D5BCF986880@AM7PR03MB6546.eurprd03.prod.outlook.com>
X-MS-Oob-TLC-OOBClassifiers: OLM:10000;
X-Forefront-PRVS: 04238CD941
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: bchO4q+Syf3vmpjClqG8c41831JZ2J+jbPXlFp5bD/8+01Bc8PUGNrJcxUoIua+cgnOL6MfFi1Q7aWtpH/OJFHJQ52nHKxtXn5xykWPx0a6uZ6Y6vltnPSeIi4TDkGOSCMr2Rj6WWkgSHVQhSGVIpN1J2Nh11sUGVaSqrGy1GcJzDlLvbT7xZkCdoBPeRWrHuXxwyS/u06bnfAJhUfqvqc5Z9EQScKm6tUn9mLLrzHReeb21Y8tKfc8YgCEqcc5cUYUFA2ncKHgV5fmR7fuqtZir2a6EXynnuNnNGIntDkAqx/palPNn2qH6JHttlzZsX5FuaAWlrLQ/EUWnVsVALGyz5oErjXq6jUqkF6XHPnGCDPECpW091qpOCl4+ZK8N
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR03MB6642.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(346002)(366004)(39850400004)(396003)(136003)(16526019)(86362001)(66946007)(52116002)(186003)(66556008)(66476007)(83380400001)(36756003)(6506007)(31696002)(6486002)(4326008)(6512007)(5660300002)(316002)(786003)(3450700001)(2616005)(478600001)(8676002)(2906002)(8936002)(110136005)(31686004)(43740500002); DIR:OUT; SFP:1102;
X-MS-Exchange-AntiSpam-MessageData: u5y+bf4YoiXTvoYFpNP8kmHnMwo+PN4iOWI5oN2Nvbwm5Lxo5vOUD7OSGEQI6JSQKNv13uY834Uh5FW8f6X758cTKfVlag21WP/tvJnn46XJfuuSorR5OMv07Ft406PEpDpd34VyjsvGMkelN+0MRKb7JvOgyaqS6a8m/SagAcmglj2WhjyAAicJbH2RgLFxYiZBMEHVOJL/0rW+XWi3EbEea+CrJCTlPEkmAgIabOvS3rOAzOolVFbeBR5RaqiBeLv4fRCbqjRWDirCCIDDi2ID/SWsivVXBjJyzJ8g1+XR4l40TY8by6F5lIolDGwupqLcbRtKa0Qmlqu7ceK9rgEuMeHKmxeXSXEAooGN6LcNp2XPJUhc+ZK1OkH5Zz7XP1gObG0tZtj00g2HqDZvkra1TtYh5Q3liBgUCNu8K/oPEKeDDrm5L/QoV96U1azZRDJZkI66hEXSBsUCPPgiD9NbxjmMfVgxL42xQdS4ij1lF8cz+h4fWEqDzzL10W+j8giL+7yhzIbter7Uw8bDemNn05biw81g811LWYxsDuFvxAWbf7lX7Kk/xgQxjr7l
X-OriginatorOrg: uclouvain.be
X-MS-Exchange-CrossTenant-Network-Message-Id: 37157a23-0d89-481d-d739-08d80787bfd4
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Jun 2020 06:31:29.5253 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 7ab090d4-fa2e-4ecf-bc7c-4127b4d582ec
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: lRFF4SuJVnJ+N56qvmANY4yUept0Rh2zjqbABCB7j5hwm572kL7aqirYn2jL8to24fADW+F/bA6HoCdXeAZpkGfprAYlqOG1TAJBHz6lVGPRn0/Q/zx8eG6ezOVPuJih
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR03MB6546
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/tCiddwlA1BLkYe09BCRS-_Qq7aE>
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: Wed, 03 Jun 2020 06:31:37 -0000

Matt,
> 
> Thank you very much for producing and sharing this document, I agree it 
> is appropriate for this forum. The diagrams in the document are 
> especially helpful.
> 
> That being said, I have a lot of concerns about the feasibility and 
> usefulness of the schemes in this document. I wonder if this usage of 
> QUIC is in the spirit of many QUIC deployments, or if it potentially 
> hinders an application's usage of QUIC. 

This ATSSS solution should be considered as another application for QUIC 
that leverages the flexibility of QUIC. With the datagram extension, it 
becomes possible to carry unreliable datagrams over a 
congestion-controlled QUIC connection to the ATSSS function that is 
provided by the network operator. This could be considered as a kind of 
operator-provided "VPN" service that allows unmodified applications 
running on enduser devices to efficiently use the available paths 
without having to modify these applications.

> Correct me if I am wrong, but it 
> seems one of the core tenets of these schemes is that user applications 
> on mobile devices would have their flows to servers transparently 
> tunneled over a multipath transport and then "untunneled" for the final 
> transit to the server. One of the benefits of QUIC in practice is the 
> ability to potentially bring the transport implementation "closer" to 
> the application than was traditionally possible with TCP. One useful 
> signal to applications is the transport's knowledge of the underlying 
> path state. By transparently tunneling a QUIC connection over multiple 
> paths this signal is lost. This has practical implications; the 
> congestion controller used by the transport cannot proactively act on 
> network switching signals, and the application cannot proactively adjust 
> its behavior either. As a trivial example, an ABR streaming video 
> application may detect that the underlying path has switched and 
> subsequently adjust the bandwidth. One could imagine partially getting 
> around this problem by implementing a channel on the UE (i.e. some sort 
> of API) through which the information about the underlying path state is 
> conveyed to the QUIC transport which is being tunneled. However, this 
> doesn't address the loss of information for the server. Additionally, I 
> would argue that if this UE informational channel exists there is no 
> need to tunnel QUIC traffic at all -- the QUIC transport being utilized 
> directly by the application can manage its use of the underlying network 
> interfaces.
> 
> Said another way, I think it would be useful to further discuss why 
> these problems need to be solved in "the network" itself rather than 
> focusing on making QUIC "natively" capable of optimally navigating 5G 
> networks.

Solving these problems in the network allows to support existing and 
unmodifed applications, which is a key requirement from a deployment 
viewpoint. A longer term approach could be to expose more information 
from the underlying network to the upper layer so that new applications 
can make informed and possibly better choices.


Olivier