Re: [tsvwg] L4S drafts: Next Steps
"Black, David" <David.Black@dell.com> Thu, 11 March 2021 20:09 UTC
Return-Path: <David.Black@dell.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 470E53A114A for <tsvwg@ietfa.amsl.com>; Thu, 11 Mar 2021 12:09:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.347
X-Spam-Level:
X-Spam-Status: No, score=-2.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.248, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dell.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 0mJtx3RD45Wd for <tsvwg@ietfa.amsl.com>; Thu, 11 Mar 2021 12:09:14 -0800 (PST)
Received: from mx0b-00154904.pphosted.com (mx0b-00154904.pphosted.com [148.163.137.20]) (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 83B4A3A1149 for <tsvwg@ietf.org>; Thu, 11 Mar 2021 12:09:12 -0800 (PST)
Received: from pps.filterd (m0170395.ppops.net [127.0.0.1]) by mx0b-00154904.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 12BK2wh6020147; Thu, 11 Mar 2021 15:08:25 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=smtpout1; bh=1yNEfZf19XvbjolFLSxmt6E1MwwSiyLoy+6EgHXYGUI=; b=tFDUoJJ2dUVfD+Dy5UyCjLrN6EBqwVv7fhT9v68jTYGT3nb0aEB9FnEP/glkM4USsG5c Gtb0NwRDBe46fmNGIZbVNFwvoWBYJpCw6M55h+j4My8+XKqOVh0GOVspnvBBDjzzPGdz KRg4H4Qe6ll7j4lYyTtNHnfFkc0UMosWCJmHwGG/SlMwo11RR4IommkMUW/5WEHljp1R 3LD52L7Ab6uE2zUn2D4Tmr9XVt9VycKU2vRqu3h4Zub3Igra1fAM/3W4s4UXj5DAPMj8 GuTJqpzJ8LdiaN5xWqBdba43K6+7J8dpLZ3J/fVydIh7kH1eCmcHCRtcVQG5v1LtysrS Pg==
Received: from mx0b-00154901.pphosted.com (mx0b-00154901.pphosted.com [67.231.157.37]) by mx0b-00154904.pphosted.com with ESMTP id 37479ujm8s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 11 Mar 2021 15:08:25 -0500
Received: from pps.filterd (m0144104.ppops.net [127.0.0.1]) by mx0b-00154901.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 12BJxmj8174053; Thu, 11 Mar 2021 15:08:24 -0500
Received: from nam02-bl2-obe.outbound.protection.outlook.com (mail-bl2nam02lp2051.outbound.protection.outlook.com [104.47.38.51]) by mx0b-00154901.pphosted.com with ESMTP id 374qyv6aj6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 11 Mar 2021 15:08:24 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nr5DMrhqHKErng1WuU44NnJgJpTPe62QGS+qLZh26ft0V3E7xNSHgP/bYSZhpPmIchRc5R2FaI1mnB+7spbeB7pIlWG5iJof6vZ9A/7Jo6QNKtE9wYX/NgPUEX8pzgeW82bX0dsjjURqS4FbFtnPeMR+q1ptMXLu5GK2a6oGMRpXgSFiJMMSnZ4LHIKW4bHiCN0nL23XinsHEkpfAEiOfdFq6zP07E46BX1g5j+Yvpv/fyxw1rlh47h85hCH8tWJjENtuNeopv8P4RNxzNFZ9XI8J2aNO4cDI8iyq+fctrL9GRgawjRT6QGS/nHCD4fAfZvgOhTqsO9Zn9zTc7nKQw==
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=1yNEfZf19XvbjolFLSxmt6E1MwwSiyLoy+6EgHXYGUI=; b=n1CY/BsVDAzqGC8Cv4qqQsBPEAUwtI06cDTo8BBq5oyZz1gepSwXQDi2XbEWKUIMiJjd+gjQaGYPooKu1SRCEuESPsgk7Z34Q8UNwVrwrtg61dlSxQbu6k/47/0hZ3izqVUPatMtR3ZSDEytPMREtecHmc4DgxcQTUkKx4BkLsieZKvSqNpEWDlcfTo72exOjJj7+kFtOcucVtWHixo/cccr+O2KnGttjg1PzZv23kndnIdzqnZ4WbAKAmSi7I+5GrcgmNZ46VoyclZbU9xlOPm25971zUPC89VaeozlWIUJcHpMo3EnLsHdPJ/J8I6kUFCJrW64Xh58bghDpgqX9Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=dell.com; dmarc=pass action=none header.from=dell.com; dkim=pass header.d=dell.com; arc=none
Received: from MN2PR19MB4045.namprd19.prod.outlook.com (2603:10b6:208:1e4::9) by MN2PR19MB3790.namprd19.prod.outlook.com (2603:10b6:208:1ee::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3912.17; Thu, 11 Mar 2021 20:08:22 +0000
Received: from MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::b1f3:f51d:c01c:2feb]) by MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::b1f3:f51d:c01c:2feb%5]) with mapi id 15.20.3912.030; Thu, 11 Mar 2021 20:08:22 +0000
From: "Black, David" <David.Black@dell.com>
To: Bob Briscoe <ietf@bobbriscoe.net>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Thread-Topic: [tsvwg] L4S drafts: Next Steps
Thread-Index: AdbKU+HDR3oMXZmiTbKSLpO/kl695wDYhNkAADC2WKARzOGwAAAKQaEAADQ4FQAAArP4wA==
Date: Thu, 11 Mar 2021 20:08:22 +0000
Message-ID: <MN2PR19MB404522F073A03BA2F866604E83909@MN2PR19MB4045.namprd19.prod.outlook.com>
References: <MN2PR19MB4045FAC079C74FC262005BF483F10@MN2PR19MB4045.namprd19.prod.outlook.com> <92283815-f81a-ba86-fe63-7925e23e31f6@bobbriscoe.net> <MN2PR19MB404513C22FE4025C31261BC783CC0@MN2PR19MB4045.namprd19.prod.outlook.com> <5d8f0031-1aee-9e41-7860-04a46a89607e@bobbriscoe.net> <MN2PR19MB4045305CA7D5673C554BCBA383919@MN2PR19MB4045.namprd19.prod.outlook.com> <ee0c9cd2-608c-ef69-ef84-892cd4f17204@bobbriscoe.net>
In-Reply-To: <ee0c9cd2-608c-ef69-ef84-892cd4f17204@bobbriscoe.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Enabled=True; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SiteId=945c199a-83a2-4e80-9f8c-5a91be5752dd; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Owner=david.black@emc.com; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SetDate=2021-03-11T19:59:34.0349793Z; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Name=External Public; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Application=Microsoft Azure Information Protection; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_ActionId=9524e42f-76ba-4bb8-a98e-13332d929999; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Extended_MSFT_Method=Manual
authentication-results: bobbriscoe.net; dkim=none (message not signed) header.d=none;bobbriscoe.net; dmarc=none action=none header.from=dell.com;
x-originating-ip: [72.74.71.221]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 75484a4a-1be1-482b-d9d3-08d8e4c96c49
x-ms-traffictypediagnostic: MN2PR19MB3790:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <MN2PR19MB3790245D6F02165E24889BDB83909@MN2PR19MB3790.namprd19.prod.outlook.com>
x-exotenant: 2khUwGVqB6N9v58KS13ncyUmMJd8q4
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: cjaQInTjg/pwJoE9MfzDB52pR+wVRxw9JhZjdKLL+1qTfXyUikmy0FnurCgzBYYndHc0z/jbXC4YlNx+0BgI0dZD3NX/ckucUJpqdGUq08r5db4nYjPuyPPfVB6UqzvkUqnztHEy07IHT4VYR+QGsqvgwHCS1GJX8sv1IGEb9qSlecdpMF44lI4UvbFcWjyi8OXB34IAdq5XPET/Qsi6uKKkkKdyQRUBzWtmqfDzNXjb5syWgxHpYvfL0FlJEDpyEZmTXd77Y0g0A+zLFbbcSyZ7qRPXLy/YFSBfUJBpbr8GgJ/w16uypg5ukpHuAxyaSGfCM07aGxmUrBZErkmq1HeZUKCWagKxgLjT7DcO7F5kNLR0yPEvaTo/Huk5ZsIVtSxL9b9n6JOdNHW1ApVZB2i5ES3nNxES+ay4pcDGk84fcw0o7+mNfwV0VKrQvzrl0bYGnkdQzD0VQ3LQ+Hfuy6oLlTv5Oif/DF6gfd81CeF14VxHtiRAq3yo6FMZZmjN2LliLdsblDmvt2gThKvLn3ijdPhju6VxMhtQfNcb+AYzMMq3a28XMkLlKQ7fPa3A7WGAQ6M/FPUNkkr6tH/7jgsKQlR+4w2jgb50iVVqH7U=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR19MB4045.namprd19.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(346002)(396003)(366004)(39860400002)(376002)(64756008)(66476007)(30864003)(53546011)(5660300002)(8936002)(66556008)(6506007)(2906002)(66946007)(110136005)(478600001)(786003)(316002)(4326008)(33656002)(8676002)(26005)(76116006)(966005)(9686003)(55016002)(66446008)(107886003)(71200400001)(83380400001)(66574015)(7696005)(16799955002)(186003)(166002)(86362001)(52536014); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: uW7Ewz3QMWfpzAbZaUmI8sghhKsooKlXDIt7i27K1VY/vHJKgjzdQEW70ESCYnzFlgbuBqoh/F8Q87Wfe0PdVRqcH0EChZGVwpdsPfdFzJXduxL1SDmGWFEf96+Gk76Nmil9/eP3U1h+WmLInO8AxMFguspJYVidpZEjpUMUUazwjyvAvdEdO65gNn+EzUwkbngmlq/lI7El1Z/xL9yw+BHCkvOB0pl7FZudfijQoz0M9DEw7HrIOVt7OodwIh9loIe0tjd1GgKLAz0GDkybLXR4G1LLRGubTIcHW/PrD4wCmdfVm+RMbpzYzVuzm8bJNvEBeTcTA51XgAVIZil4AzsPOOmApRSH3gi/0zDtGP8Kb2gHR7TdGAHsab3GHHbwmsQQ6pE3JuTjS21fOqlTBFxnRl0yDYsjqWI5BKFKENgUIG/2g/ueSdAtwLgaWBR1cu+GIFVCz7m+4p4VUIkgPQiQ07k4amhUj8gVSjLjEIYD5+Mh60j5S4DdusqLiHEgVTegWTfyiwI2abHOB40fiGjdLzqq1rSKEOfabZsK1hsxZcgnPY2BDx+tCJscL4iQkNTTiew5osu+XVKZjaBjLeScoD9enZWmdhC3ToDC0c7zUvfSLWUofHC6/lPgML67759lOXoqM7OwKpGkXgCMpfXr9dISkFbNnnOvHo0sZpP2U+MlqlWPqa+Osb8BvVS+8ySnQNTtxUncFjm7ngUrFHl/ORHe6J91aA/Q9wK1L5WDhZgJPQfXRlXJyq1J6OcBmrp4fpxdasTCEmH6u4bYhYEhsifxwszyrEDCiswMmw4lffnNgDid1fX35jIVEc1a31JHAUN/Rwa9kNlr7LatLJ2apyhe1C+zplUQTyhIXdrALfgZLIA8aIaofVeBb9f9yvIS4zxFsF0/mbGY7mV06Xj4Ly3GO4Mhz3wEi2z7udWyEvVynVZt9PXXLh442AV3nU3YqHFPBusS3LNRFORBla2sjWfpgMOd84M9OBhLm/pcs9dn3mzzgU+wI5fCrK5WHydH0tJULPdRzuzHt8jXtjY89VLxrY350lGhKqzuUSiIu3IGbjWHynFgpU7VwTfsIsz8Rs1ewx56LarKNM5XFURYqUVSOJ8/jl70Rddob3RuSiGK689yxo4IUnNF6j1NSQrUmA8FsrN4XzzdzanXLALP1YzDeYJub4OmL7QvyjRe27B5WQGLaWvHEuPkwNP6nabkZkWut/jIihmN5jX5FGUmpbbX2eURwhjhyKX4aiHq55CEDY5saWtpYq1j9sc9dGZ04wJeEUTBoCstyEvhM2O8P7gNUlESFuf+WUWOptC8hlNlETIPzWABQgCxHdR0
Content-Type: multipart/alternative; boundary="_000_MN2PR19MB404522F073A03BA2F866604E83909MN2PR19MB4045namp_"
MIME-Version: 1.0
X-OriginatorOrg: Dell.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR19MB4045.namprd19.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 75484a4a-1be1-482b-d9d3-08d8e4c96c49
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Mar 2021 20:08:22.7332 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 945c199a-83a2-4e80-9f8c-5a91be5752dd
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: MtjH9+Z9Pk4cNeBQUefKMtY3KXF/UZPeKqtbxxgrmwf4iFY3sj8su/IQyp3GvEsDtUSRXBLSqlhNyqPLwSzKig==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR19MB3790
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-03-11_08:2021-03-10, 2021-03-11 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 phishscore=0 malwarescore=0 priorityscore=1501 suspectscore=0 clxscore=1015 bulkscore=0 adultscore=0 impostorscore=0 lowpriorityscore=0 mlxscore=0 mlxlogscore=999 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2103110103
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 adultscore=0 bulkscore=0 suspectscore=0 mlxscore=0 phishscore=0 spamscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2103110103
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/iRvIlJaJ1A4OV81uGLjwK9y9xGI>
Subject: Re: [tsvwg] L4S drafts: Next Steps
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: Thu, 11 Mar 2021 20:09:18 -0000
>> 1. Transport-protocol-independent requirements to use L4S service >> - Goal: Interoperability - multiple transport protocols able to meet requirements >> * Specifications and/or implementations - WG decides what is sufficient >> - Location: draft-ietf-tsvwg-ecn-l4s-id >> > [BB] I think the number 'two' comes from wanting to be sure that developers other than the author-team can understand the spec. sufficiently to implement. > > Pls confirm that could also be satisfied by /each/ requirement having been implemented by /at least one other/ team than the authors (or reasonably expected to implement). No, definitely not confirmed. Use of the ECT(1) codepoint entails meeting all the requirements. If only TCP Prague will be able to meet all the requirements, then that set of requirements for ECT(1) codepoint usage is not transport-protocol-independent. Thanks, --David From: Bob Briscoe <ietf@bobbriscoe.net> Sent: Thursday, March 11, 2021 1:42 PM To: Black, David; tsvwg@ietf.org Subject: Re: [tsvwg] L4S drafts: Next Steps [EXTERNAL EMAIL] David, On 10/03/2021 18:01, Black, David wrote: Bob, Reproducing text from the slide used in today's meeting: ------------------------ L4S Drafts: What Needs To Be Done 1. Transport-protocol-independent requirements to use L4S service - Goal: Interoperability - multiple transport protocols able to meet requirements * Specifications and/or implementations - WG decides what is sufficient - Location: draft-ietf-tsvwg-ecn-l4s-id 2. Safety of Internet-wide L4S experiment - Goal: L4S experiment unlikely to cause significant damage to the Internet, and * Any damage that results is expected to be tolerable - Location: draft-white-tsvwg-l4s-ops (candidate for WG adoption) * WG Last Call on l4s-ops draft not required to meet safety goal * Criteria: WG "rough consensus" that each goal has been reached - WG chairs will run initial consensus calls before next IETF meeting week ------------------------ This discussion is about the first goal: Transport-protocol-independent requirements to use L4S service > I accept that we're messing with core protocols here, so the bar should be higher. > But, 2 independent full implementations for an EXP would be way beyond any interpretation of IETF process. Two independent full implementations of protocols that meet the requirements ought to suffice, but may not be necessary. As stated on the slide (and quoted above): " Specifications and/or implementations - WG decides what is sufficient." [BB] I think the number 'two' comes from wanting to be sure that developers other than the author-team can understand the spec. sufficiently to implement. Pls confirm that could also be satisfied by /each/ requirement having been implemented by /at least one other/ team than the authors (or reasonably expected to implement). The reason this is important is that there is a heavy performance evaluation burden attached to each requirement, because they are nearly all about impact on the queuing delay of other hosts (or impact on throughput of others in the case of the Classic ECN AQM one). For a second CC developer to invest the time and effort in the performance testing necessary for every requirement, they would have to be very confident that the IETF was going to follow through with codepoint assignment. A great job has been done in undermining that confidence in the last couple of years. To be clear, there are many implementations of the network part, and a load of network operators ready to deploy the network part. There's no problem there (other than all those projects have gone cold waiting for the IETF). The focus here is CC development, I assume. > This part of your original email (which was as a chair) asked us to /restructure/ the drafts. I said they already have the structure you want. > No reply to that point. Now what you talk about above (albeit as an individual now) are wording changes not restructuring. > We've been doing wording changes with the survey of implementers. Fine with that. > > But I'd like confirmation (as a chair) that restructuring is not needed. Confirmed. Good. Thank you. Bob Thanks, --David (as a TSVWG chair) From: Bob Briscoe <ietf@bobbriscoe.net><mailto:ietf@bobbriscoe.net> Sent: Wednesday, March 10, 2021 7:53 AM To: Black, David; tsvwg@ietf.org<mailto:tsvwg@ietf.org> Subject: Re: [tsvwg] L4S drafts: Next Steps [EXTERNAL EMAIL] David, As you've just pointed this old thread out, I'll continue on this thread. See [BB] inline... On 09/12/2020 22:28, Black, David wrote: Bob, Reminder of the goal for [1] (Rework the "Prague Requirements" into the following two entities ...): >> Success of this exercise will be judged by the WG reaching "rough consensus" that multiple transport protocol implementations >> currently meet and/or are reasonably expected to be able to meet the normative requirements (a). If the L4S folks believe that this has already been done, then it's time to start bringing forward the multiple transport protocols that demonstrate success of that exercise. [BB] This is understood and fine. This is where our focus is. I assume readers are aware that the IETF's requirement for 2 independent implementations is for progressions from Proposed Standard to full Internet Standard, and few RFCs have ever taken that step (only 118 RFCs are STDs or parts of STDs) (e.g. RFC3168 is not). https://www.rfc-editor.org/search/rfc_search_detail.php?sortkey=Number&sorting=DESC&page=All&pubstatus%5B%5D=Standards%20Track&std_trk=Internet%20Standard I accept that we're messing with core protocols here, so the bar should be higher. But, 2 independent full implementations for an EXP would be way beyond any interpretation of IETF process. >Nonetheless, if there are specific items in S.4 that someone believes should or shouldn't be there, or should be worded differently, let's have those discussions now on the list - I'm all ears Speaking only for myself as an individual beyond this point, these two normative requirements struck me as ones that might be better stated as design and implementation guidelines: o A scalable congestion control MUST eliminate RTT bias as much as possible in the range between the minimum likely RTT and typical RTTs expected in the intended deployment scenario (see Appendix A.1.5<https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-l4s-id-12#appendix-A.1.5> for rationale). o A scalable congestion control SHOULD remain responsive to congestion when typical RTTs over the public Internet are significantly smaller because they are no longer inflated by queuing delay (see Appendix A.1.6<https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-l4s-id-12#appendix-A.1.6> for rationale). The use of "as much as possible" in the first bullet makes it hard to figure out whether a specific congestion control meets that mandatory requirement for participation in the L4S experiment. The second bullet appears to involve a prediction of the future as currently written. [BB] I'll refrain from getting into text-specifics in this thread, 'cos I'm trying to be absolutely sure I understand what the chairs want. We've felt subjected to a "No, bring me a different rock" process so far, so we want to be absolutely clear what sort of rock you want. This part of your original email (which was as a chair) asked us to /restructure/ the drafts. I said they already have the structure you want. No reply to that point. Now what you talk about above (albeit as an individual now) are wording changes not restructuring. We've been doing wording changes with the survey of implementers. Fine with that. But I'd like confirmation (as a chair) that restructuring is not needed. ============================================================================================== FYI, here's the structure of the transport requirements (I already explained this in the previous email in this thread): ecn-l4s-id * Sec.4. (Normative) Transport Layer Behaviour All the factors that involve potential harm to others (containing MUSTs and now some SHOULDs) With a pointer from each one to further guidance in Appx A.1 * Sec 5 (Normative) Network Node Behaviour ... * Appx A.1 (Informative) Requirements for Scalable Transport Protocols Guidance on features that involve potential harm to others * Appx A.2 (Informative) Scalable Transport Protocol Optimizations Guidance on features that would benefit the flow itself draft-briscoe-iccrg-prague-congestion-control (just posted) * Detailed guidance, specification, implementation notes, etc. Bob Thanks, --David From: Bob Briscoe <ietf@bobbriscoe.net><mailto:ietf@bobbriscoe.net> Sent: Tuesday, December 8, 2020 6:01 PM To: Black, David; tsvwg@ietf.org<mailto:tsvwg@ietf.org> Subject: Re: [tsvwg] L4S drafts: Next Steps [EXTERNAL EMAIL] David and chairs, On 04/12/2020 15:54, Black, David wrote: The WG chairs have consulted among ourselves and with our AD (Martin Duke). Our guidance to the WG and the L4S draft authors is that at least the following two things need to be done before WGLC will become possible on the L4S drafts: [1] Rework the "Prague Requirements" into the following two entities, which will overlap: 1. Transport-protocol-agnostic normative requirements for all congestion-controlled traffic that uses the L4S low latency queue. 1. The DualQ AQM design relies upon traffic adhering to these requirements. 2. Design and implementation guidelines for new congestion controls that meet the normative requirements (a). 1. Ultimately, the choice of whether a particular aspect is a guideline (b) or requirement (a) is a WG "rough consensus" decision. [BB] I believe draft-ietf-tsvwg-ecn-l4s-id is already structured for this division between normative requirements and design and implementation guidelines. * [1]a) is Section 4 "Prerequisite Transport Layer Behaviour". Nearly every paragraph also refers off to subsections of Appendix A.1 for extra non-normative info, headed "Requirements for Scalable Transport Protocols". [Actually, it might be useful to swap these two headings] * [1]b) is Appendix A.2: "Scalable Transport Protocol Optimizations" The rule that determined which aspect went in which was: [1]a) if it's about an aspect of one transport's behaviour that has potential to impact/harm others [1]b) if it's solely about how a transport can improve it's own performance. They have been divided like that from the very first ad hoc meeting in Prague that formulated them (in 2015) Code to address all the requirements and most of the optimizations has been implemented. Over the last year, 3 or 4 of the later requirements in a) have become SHOULDs not MUSTs. Personally I would have left most as MUSTs, but I've tried to reflect what the WG wanted. Those demoted to SHOULD have generally been considered a lower risk of harm (either low likelihood of occuring or minor harm if they do) - taking into account the complexity of implementing them. We could certainly flag the point where the transition from MUSTs to SHOULDs occurs within section 4. But I think we should still group all the items with potential for harm together in the same section. Because assessment of risk will change as the Internet landscape changes (possibly over the duration of the experiment). Now I've explained, I hope the chairs will all agree that "rework the Prague Requirements into two entities" (normative requirements and design and implementation guidelines) is already done and dusted. Nonetheless, if there are specific items in S.4 that someone believes should or shouldn't be there, or should be worded differently, let's have those discussions now on the list - I'm all ears. Bob Success of this exercise will be judged by the WG reaching "rough consensus" that multiple transport protocol implementations currently meet and/or are reasonably expected to be able to meet the normative requirements (a). [2] Build the safety case for L4S experimental Internet-wide deployment in the L4S Ops draft. 1. This safety case does not rely on endpoints running TCP Prague, though it can assume endpoints are meeting the reworked Prague requirements 2. Ops draft will provide guidance on how to detect L4S problems on their RFC 3168 network, and how to mitigate them. 3. Ops draft must consider these scenarios: 1. An unsophisticated user purchases an L4S endpoint and runs it on a service provider's single-queue RFC 3168 network. 2. L4S traffic from another domain enters an RFC 3168 single-queue network (e.g. a peer-to-peer application) Success of this exercise will be judged by the WG reaching "rough consensus" that deployment of the L4S experiment is unlikely to cause significant damage to the Internet, and that any damage that results is expected to be tolerable. Thanks, --David [as TSVWG WG co-chair] ---------------------------------------------------------------- David L. Black, Senior Distinguished Engineer Dell Technologies, Infrastructure Systems Group 176 South St., Hopkinton, MA 01748 +1 (774) 350-9323<tel:+17743509323> Mobile: +1 (978) 394-7754<tel:+19783947754> David.Black@dell.com<mailto:David.Black@dell.com> ---------------------------------------------------------------- -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/
- [tsvwg] L4S drafts: Next Steps Black, David
- Re: [tsvwg] L4S drafts: Next Steps Bob Briscoe
- Re: [tsvwg] L4S drafts: Next Steps Black, David
- Re: [tsvwg] L4S drafts: Next Steps Jonathan Morton
- Re: [tsvwg] L4S drafts: Next Steps Sebastian Moeller
- Re: [tsvwg] L4S drafts: Next Steps Wesley Eddy
- Re: [tsvwg] L4S drafts: Next Steps Ingemar Johansson S
- Re: [tsvwg] L4S drafts: Next Steps Bob Briscoe
- Re: [tsvwg] L4S drafts: Next Steps Black, David
- Re: [tsvwg] L4S drafts: Next Steps Bob Briscoe
- Re: [tsvwg] L4S drafts: Next Steps Black, David
- Re: [tsvwg] L4S drafts: Next Steps Bob Briscoe
- Re: [tsvwg] L4S drafts: Next Steps Jonathan Morton
- Re: [tsvwg] L4S drafts: Next Steps Bob Briscoe
- Re: [tsvwg] L4S drafts: Next Steps Jonathan Morton
- Re: [tsvwg] L4S drafts: Next Steps Black, David
- Re: [tsvwg] L4S drafts: Next Steps Bob Briscoe
- Re: [tsvwg] L4S drafts: Next Steps Black, David
- Re: [tsvwg] L4S drafts: Next Steps Gorry Fairhurst
- Re: [tsvwg] L4S drafts: Next Steps Greg White
- Re: [tsvwg] L4S drafts: Next Steps Gorry Fairhurst
- Re: [tsvwg] L4S drafts: Next Steps Sebastian Moeller
- Re: [tsvwg] L4S drafts: Next Steps Livingood, Jason
- Re: [tsvwg] L4S drafts: Next Steps Jonathan Morton
- Re: [tsvwg] L4S drafts: Next Steps Livingood, Jason
- Re: [tsvwg] L4S drafts: Next Steps Gorry Fairhurst
- Re: [tsvwg] L4S drafts: Next Steps Jonathan Morton
- Re: [tsvwg] L4S drafts: Next Steps Sebastian Moeller
- Re: [tsvwg] L4S drafts: Next Steps Sebastian Moeller
- Re: [tsvwg] L4S drafts: Next Steps Pete Heist
- Re: [tsvwg] L4S drafts: Next Steps Sebastian Moeller
- Re: [tsvwg] L4S drafts: Next Steps Sebastian Moeller