Re: [tsvwg] closing L4S issue #17 on FQ interaction

Greg White <g.white@CableLabs.com> Wed, 05 February 2020 21:08 UTC

Return-Path: <g.white@CableLabs.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5AAC12081D for <tsvwg@ietfa.amsl.com>; Wed, 5 Feb 2020 13:08:10 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cablelabs.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 2PCVjBakrLL7 for <tsvwg@ietfa.amsl.com>; Wed, 5 Feb 2020 13:08:09 -0800 (PST)
Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2111.outbound.protection.outlook.com [40.107.220.111]) (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 D6CBF120838 for <tsvwg@ietf.org>; Wed, 5 Feb 2020 13:08:08 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=R1poq8rEU7l/hSUhp8qTEkyZW1DiHbKV8J4xS8SWLycsyLi9QhWL2IcpFpw88C3dZgdJpdQfa7/hR5K3VNrnN0v8NRq35E3B+tMGWPVX85iSWE52RgeDDumpcHur67927dYaA7Ua40vZM7/SBQdhKoy1ECkxujJdv5O0Lt5IbSJDWxWr/HU2hbw/Hb30Lwbs4zNxEMMot46EXrGXIB1ZrS3HOguzli0cg6dOnQ84FdgY7vLULoafP0En1doi+6vzgrSze4uV0qFCIVDlfsHbQ0CdQSTUcTaJYL3i43lYX+Ac1q2JgPEQ2O1kY+OkKGSFh9vLeIIa+TKWn922G0MIcw==
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=a/BDk1Dv+OWUK7VKh0RoMxwRgN/czZMh7HOYgpmDj1o=; b=Q8eSPH0z7qu/3YjLY82ybUjvrBiVo2zt15FEGOlkOa3nre+Bc6iBPE3ksoe5KpCYZlT17cQIszeIruvSWfNi2jvINiu221RhRCpDsWErSp3amO4XiVYRtJ7PANoQHVavmE4fRK0igqXYsj6Qd2XJxroj6maO+jgesqc2sqNeiQlfOfpNfNLmjfy4Meuu+yBhr4SGc6JqZJ7R18tDyBp51Kvw+858XWKab/LqU+tyoz5nYnZLBHgC4wSUoakWZ3Q9cBsGwJo0s7bgL6MP2Im1RFJwMdjHlKXQ3iq0pJnaeO5V1aBeA1OOh+CsO/hiqtdeAOoVGWqdcJjT8hbc5hnRdw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cablelabs.com; dmarc=pass action=none header.from=cablelabs.com; dkim=pass header.d=cablelabs.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cablelabs.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=a/BDk1Dv+OWUK7VKh0RoMxwRgN/czZMh7HOYgpmDj1o=; b=iq7azUZH8R5Xbky5jkxRjlH2r17f0rIV08q2xf6DRte9CJIob6oWzFzYwgPWdGixMMUUjwmMp57Ykhy7iPulzvLwD1NHmAGvHnYM8Yuy+RSVFZ4J1aboifX+fA708dioG0VHQbFXrHdTPVypsv4JN9OI8SEDOhldOokw3Bn86pM=
Received: from DM5PR06MB3564.namprd06.prod.outlook.com (10.174.190.34) by DM5PR06MB3097.namprd06.prod.outlook.com (10.174.191.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2707.21; Wed, 5 Feb 2020 21:08:06 +0000
Received: from DM5PR06MB3564.namprd06.prod.outlook.com ([fe80::253f:ea06:3b1a:242]) by DM5PR06MB3564.namprd06.prod.outlook.com ([fe80::253f:ea06:3b1a:242%3]) with mapi id 15.20.2686.031; Wed, 5 Feb 2020 21:08:06 +0000
From: Greg White <g.white@CableLabs.com>
To: Jonathan Morton <chromatix99@gmail.com>, Wesley Eddy <wes@mti-systems.com>
CC: "tsvwg@ietf.org" <tsvwg@ietf.org>
Thread-Topic: [tsvwg] closing L4S issue #17 on FQ interaction
Thread-Index: AQHV23FtFxHogqYJZkCIwzDCgglW1KgL6LqAgAC5jQCAAALjAP///1GA
Date: Wed, 5 Feb 2020 21:08:06 +0000
Message-ID: <9210F28D-1906-478F-85E9-1571152E1E8D@cablelabs.com>
References: <862c1335-1ca7-d82c-3586-8753a18533c0@mti-systems.com> <3E66D0DC-5B53-4F05-BEA4-07AC83DEE18E@gmail.com> <3fadcc65-5d51-9c05-bda5-16b18336f8df@mti-systems.com> <9A6FF03C-BEAB-4D48-BD26-07D34248A61B@gmail.com>
In-Reply-To: <9A6FF03C-BEAB-4D48-BD26-07D34248A61B@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1c.0.190812
authentication-results: spf=none (sender IP is ) smtp.mailfrom=g.white@CableLabs.com;
x-originating-ip: [2620:0:2b10:22:419a:d7b8:971b:ba7a]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 3a06977b-a8c6-4f5f-4592-08d7aa7f7f1f
x-ms-traffictypediagnostic: DM5PR06MB3097:
x-microsoft-antispam-prvs: <DM5PR06MB3097E7DB43A6CEAC3F29E730EE020@DM5PR06MB3097.namprd06.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0304E36CA3
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(366004)(189003)(199004)(66476007)(71200400001)(53546011)(33656002)(6506007)(2906002)(5660300002)(76116006)(91956017)(498600001)(966005)(64756008)(86362001)(66946007)(66446008)(66556008)(186003)(2616005)(110136005)(6512007)(6486002)(8676002)(81156014)(36756003)(81166006)(8936002)(4326008)(85282002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR06MB3097; H:DM5PR06MB3564.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: CableLabs.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: H9U49SYgNLYtwt+bM3FBgKotFjPEdtcz/5XuJPTJXRSZQgz7U3x8wLLty3+JpMQXbDtVvT1EQftI2BLHSTPip1KTbDTc4sc7FBNBz6SqeITsABryPS3QaRvcI9UN429FJsE4g9IA9613uYQs+sH7EUd/ipTwVI9ElatHu2aPWY94xmiQBLeRudC/GWjoMm3iZEkNf0oh6/VmyhQyIFXnNLTWIlrhOTQ/gXxISgmXGDSAsJqhKEPMTGI+wdOAGcOteX3z/mYsDxEkwzl4dfF8QmsltmkLJluYj+HLqm3tXMQSp9SfbYk2VOaWQrgwO6o2tdyev+p0YWIScGVMafzJgYCxprO8Xs3NOvD3ZCAnx1pJiwsUEn2nESiegC8NcXULJMgvo61LbV5a4Z6XPvyVjskUZlLJK/bEeIQmg0x518jpjkcQS8gcvyeVGHuVpL2u7rr0Oz3bjaj9UQHFCyXDFdqC3z74xlbyOhBBr1uz5Hb0IjdeIu8xtLy9Zp7jeGZdxBKiBeHgxvnke5o4QZDTAxbW39xPRKGEEf/IhpAxtiyi23Wa5rIpwksC4f+rW+9U
x-ms-exchange-antispam-messagedata: Jin7UQ1GEUbWNg+Rtg5EBmTozR20ptQgXO+1QE6g9ifTVleTIpPfyPLTNy36ko163geb6BzaP2p/ZPhuDsNRgpKPyGdqakQ2ALzLit32gUkwXRgWn25odi7GufEKaosl5oCyUS40Gm/F0NJwHxb2R1anob0jE4YoetWaP7GB5Rbbt/oYKGlDcEGt4dJYZnyV4n/ze6cmsdKMdN0a79dVcQ==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <705335860E557343BDFDEB97039E974A@namprd06.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: cablelabs.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3a06977b-a8c6-4f5f-4592-08d7aa7f7f1f
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Feb 2020 21:08:06.5499 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: ce4fbcd1-1d81-4af0-ad0b-2998c441e160
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: mpmRRJo3U2BsjXYuV39901XXk4ma+DfHQV09UUnI6gTv1AYRjoD9K3KvoqZNyYgSQHv3iKy0t7g5bIWA5m3Idg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR06MB3097
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/pAVi6TKux85ehi-KSCbyWoxpuHU>
Subject: Re: [tsvwg] closing L4S issue #17 on FQ interaction
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Feb 2020 21:08:11 -0000

This seems to me to be a different issue than what was described in Issue 17 originally (which in my eyes was a concern that L4S flows would cause collateral damage to classic TCP flows in a cascading bottleneck topology).  So for clarity I think we should close Issue 17 and (if need be) track this separately.

This topic was discussed in comments 8-10 of Issue 17, https://trac.ietf.org/trac/tsvwg/ticket/17#comment:8. 
It is already included in the Issue 16 discussion as well.  Quoting from the Issue 16 tracker (https://trac.ietf.org/trac/tsvwg/ticket/16#comment:4 ):
"In its present form, an L4S sender made available for public testing reacts very slowly to congestion signals produced by existing Codel-family AQMs. Induced queuing delays reach approximately 125ms over a 10ms baseline RTT, and a standing queue persists for several seconds before being brought under control."

If we want to track this separately from Issue 16, then it should be its own Issue, as opposed to tracking it in the comments of Issue 17.

From what I've seen there are two concerns relating to RFC3168 bottlenecks. 
1. Single queue RFC3168 bottlenecks. These are presumed to be rare, but the concern is that L4S flows will cause competing classic flows to starve.  This is discussed in Issue 16.
2. FQ-CoDel RFC3168 bottlenecks (this issue). These are presumed to be more common than the single queue version, and the concern is that these bottlenecks will cause L4S flows to see greater latency than classic flows do.  A parallel concern is that these FQ-CoDel bottlenecks cause classic TCP to underutilize the link. As noted above, this is currently discussed in Issue 16 and the later comments in Issue 17.

The proposed solution for 1 is RFC3168 detection/fallback.  While I believe that RFC3168 detection/fallback could also address the latency concern in 2, a better (though longer-term) solution is to update FQ-CoDel bottlenecks (both to support L4S-style ECN marking, and to improve handling of classic TCP flows).  Since the solution space is a bit different between these two, perhaps that provides an argument for tracking them separately?

-Greg



On 2/5/20, 7:10 AM, "tsvwg on behalf of Jonathan Morton" <tsvwg-bounces@ietf.org on behalf of chromatix99@gmail.com> wrote:

    > On 5 Feb, 2020, at 4:00 pm, Wesley Eddy <wes@mti-systems.com> wrote:
    > 
    >> I have just added https://trac.ietf.org/trac/tsvwg/ticket/17#comment:10 to reflect my thoughts on this issue.
    > 
    > Thanks Jonathan; I have a quick follow-up question to make sure it's clear for the editors what their next steps should be.
    > 
    > Is it sufficient if they're adding an open issues / future work section to list this as an area for potential research and improvement with the experimental L4S deployments and transports being created for it based on TCP Prague requirements?
    
    No, I think this is fundamental enough (along with the closely related issue #16) to require a demonstrated working solution, rather than mere aspirations towards future research.
    
    SCE represents what such a demonstrated working solution might look like.  The difference is in the signalling mechanism, which remains RFC-3168 compatible by design.  L4S differs in this respect, which is why I consider it a fundamental design issue.
    
     - Jonathan Morton