Re: [tcpm] [tsvwg] L4S status tracking

"Black, David" <David.Black@dell.com> Fri, 23 August 2019 14:24 UTC

Return-Path: <David.Black@dell.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90C4B1200CE; Fri, 23 Aug 2019 07:24:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 header.b=F+SuD6uw; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=UOqrwSrz
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 43rcF9d5xKqF; Fri, 23 Aug 2019 07:24:47 -0700 (PDT)
Received: from mx0a-00154904.pphosted.com (mx0a-00154904.pphosted.com [148.163.133.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 CC2C01200C1; Fri, 23 Aug 2019 07:24:47 -0700 (PDT)
Received: from pps.filterd (m0170390.ppops.net [127.0.0.1]) by mx0a-00154904.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x7NEK5Wf020256; Fri, 23 Aug 2019 10:24:42 -0400
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=NokOdWYuFUFwZ8b+26EesZY1ufyPCkK9VMPekrQng/s=; b=F+SuD6uwqSvXMaWKAsEkABlUsAQTs9IYM68lkqUbO8Q5EOvJ7vHWulydjTLtnlMNJN68 v3sqVYwT+3+CuJxCsQHeBtNmsIYB6Y5IvxeDuT42SG9VKHHlxXkMTvORMNdsXcb/mg51 aGPrNMfY7wW4bYSDMWgBBUm2yIMbfJAMx+uzlP5PU42maXYlAkc0ZfFwUVO2cH3Plnp0 akPG8j7D7Vxxmt1IjvCuUG/WrxkkBpS/N1V9CWAOqm6TFR4sEBbcMC1xFkNqZu/SWHUf sQ8V0n/tXZwj23kJsaI3rBQ0FzHq5sB8fWCF8cOFWGfCm099gJfxt6bBzC6xJxqIuSTZ YQ==
Received: from mx0a-00154901.pphosted.com (mx0b-00154901.pphosted.com [67.231.157.37]) by mx0a-00154904.pphosted.com with ESMTP id 2uj2883f35-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 23 Aug 2019 10:24:41 -0400
Received: from pps.filterd (m0089484.ppops.net [127.0.0.1]) by mx0b-00154901.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x7NEN4gs081102; Fri, 23 Aug 2019 10:24:29 -0400
Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by mx0b-00154901.pphosted.com with ESMTP id 2ujgrqs4xw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 23 Aug 2019 10:24:29 -0400
Received: from maildlpprd02.lss.emc.com (maildlpprd02.lss.emc.com [10.253.24.34]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x7NEO2Gi007093 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 23 Aug 2019 10:24:28 -0400
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com x7NEO2Gi007093
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1566570268; bh=A6wF1IwxoanagANzzqoM+0Kr7pA=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=UOqrwSrzsoGShxkLKCn/NdUv48YeNWgXrQuuv4pJf1PsRD0V8nhRtPWu9ZE4CmRnt DKooNrhPl0D9c9AVbCsRlxO5J8xzyN/O4voG5Ln+ACJTqLNZheXvgsMM7jzzBcP3hw dhYlNfDXaT3Bs5BfslHVVbUd0hjFEMepSG23A3vc=
Received: from mailusrhubprd04.lss.emc.com (mailusrhubprd04.lss.emc.com [10.253.24.22]) by maildlpprd02.lss.emc.com (RSA Interceptor); Fri, 23 Aug 2019 10:23:13 -0400
Received: from MXHUB311.corp.emc.com (MXHUB311.corp.emc.com [10.146.3.89]) by mailusrhubprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x7NENFow014475 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Fri, 23 Aug 2019 10:23:15 -0400
Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB311.corp.emc.com ([10.146.3.89]) with mapi id 14.03.0439.000; Fri, 23 Aug 2019 10:23:15 -0400
From: "Black, David" <David.Black@dell.com>
To: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>, Wesley Eddy <wes@mti-systems.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>
CC: "tcpm@ietf.org" <tcpm@ietf.org>, "Black, David" <David.Black@dell.com>
Thread-Topic: [tsvwg] L4S status tracking
Thread-Index: AQHVUALCgTMTYGQiSken9mWnC5q35qcJGX2A///CdDA=
Date: Fri, 23 Aug 2019 14:23:14 +0000
Message-ID: <CE03DB3D7B45C245BCA0D243277949363069B90D@MX307CL04.corp.emc.com>
References: <8321f975-dfe7-694c-b5cc-09fa371b9b61@mti-systems.com> <6EC6417807D9754DA64F3087E2E2E03E2D40EB7E@rznt8114.rznt.rzdir.fht-esslingen.de>
In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D40EB7E@rznt8114.rznt.rzdir.fht-esslingen.de>
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=2019-08-23T14:23:13.7219103Z; 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_Extended_MSFT_Method=Manual; aiplabel=External Public
x-originating-ip: [10.238.21.131]
Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D243277949363069B90DMX307CL04corpem_"
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd04.lss.emc.com
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-23_05:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908230149
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908230149
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/SZSm3cdSnmBkk1_3zR-NTuPoAcY>
Subject: Re: [tcpm] [tsvwg] L4S status tracking
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Aug 2019 14:24:50 -0000

> Note that I do not object to the terms "classic ECN", "legacy ECN", "legacy AQM" or the like, i.e.,

> if the context is ECN and not specifically TCP or the TCP congestion control. I believe it is up to

> the TSVWG do decide if this term shall be used for compliance to RFC 3168. I have no strong opinion on that.

> As far as I can see, most use of the term "classic" is in this context and I don't ask for changes in those cases.

"RFC 3168 ECN" is the more precise term, whose use I would encourage.  Use of "classic ECN" seems ok, as long as the draft makes it clear that "classic" means "RFC 3168" in this context.

Thanks, --David (as an author of RFC 3168)

From: tsvwg <tsvwg-bounces@ietf.org>; On Behalf Of Scharf, Michael
Sent: Friday, August 23, 2019 10:01 AM
To: Wesley Eddy; tsvwg@ietf.org
Cc: tcpm@ietf.org
Subject: Re: [tsvwg] L4S status tracking


[EXTERNAL EMAIL]

Hi Wes,



I'd like to add a smaller item that is mostly editorial and can hopefully be sorted just out by re-wording, albeit it may require a careful analysis of all documents.



As already noted in https://mailarchive.ietf.org/arch/msg/tsvwg/zZkYZKF-hDvWO3I5MudwpNkKyHY<https://mailarchive..ietf.org/arch/msg/tsvwg/zZkYZKF-hDvWO3I5MudwpNkKyHY> , I object to the terms "traditional TCP" and also "classic TCP" or "legacy" TCP when referring to a TCP implementation according to IETF standards-track RFCs.



To me as a non-native native speaker, all these terms have a negative connotation. I also think this language is typical to marketing material.



My prefered term when referring to TCP according to standards-track specification is "standard TCP". I would also be fine with other terms as long as they are neutral and make clear that experiments do not replace, deprecate, or outperform standards.



Similarly, I think that term such as "classic" is not appropriate for the TCP standard congestion control ("Reno"). As of today, this is the TCP congestion control algorithm on standards track that has IETF consensus. The term in the TCPM charter is "TCP standard congestion control". I also think that terms such as "Reno-compatible" or the like would be neutral.



Note that I do not object to the terms "classic ECN", "legacy ECN", "legacy AQM" or the like, i.e., if the context is ECN and not specifically TCP or the TCP congestion control. I believe it is up to the TSVWG do decide if this term shall be used for compliance to RFC 3168. I have no strong opinion on that. As far as I can see, most use of the term "classic" is in this context and I don't ask for changes in those cases.



Some use of the term "Classic Service" may also require careful review to clearly separate it from TCP Standard behavior.



Note that some use of the term "Classic TCP" would probably also apply to "Classic QUIC" once the QUIC standard is finished. To me as a non-native speaker, it would be really strange to use the term "classic" in the context of a brand-new transport protocol. IMHO in that case the term "classic" would be even more confusing.



I also add the TCPM list in CC to ensure consistency.



Thanks



Michael (with no hat)





Von: Wesley Eddy<mailto:wes@mti-systems.com>
Gesendet: Sonntag, 11. August 2019 07:08
An: tsvwg@ietf.org<mailto:tsvwg@ietf.org>
Betreff: [tsvwg] L4S status tracking


I created tickets in the TSVWG "trac" tool in order to help keep track
of the individual things that look like they should be addressed in
progressing L4S document set:

https://trac.ietf.org/trac/tsvwg/report/1?sort=ticket&asc=1&page=1

I'll try to update these based on the ongoing discussions, updates,
etc., but it will make it very easy if you happen to mention the ticket
numbers or some key words in threads and messages, when significant.