From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 lists.bufferbloat.net (Postfix) with ESMTPS id 73E3F3CB37 for ; Fri, 26 Jul 2019 16:01:44 -0400 (EDT) Received: from pps.filterd (m0170391.ppops.net [127.0.0.1]) by mx0a-00154904.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x6QJdfeq024027; Fri, 26 Jul 2019 16:00:57 -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 : content-transfer-encoding : mime-version; s=smtpout1; bh=0RX0LULrMStzjZ5nWk4ARn1Wucl4+VHtgTzOhTRkD3s=; b=N3X+HWDGrA0ZAFW3VwOIp3ds6DWTgQYRJw+xMQQo8nTD8kzrYb/zmMo2xfc/9PNHNKRu DBGSAmkR4NCevqMjPV4xS6rpiRLIXCo7/YxOYssO1X38E74T/UAzWz75Ksmo4/VGRmgA EuE7Pvd4NM9OqfjfjABhL7U1XKPBtkG+zxx39LRie4rIW067wjvnUxej13IKwDTm5t9U V5XiwTCvO39tCzOshPCekJX4eWfhXgARSlklbyNOg7CF9hRqyIk6CYah1rxjdKeqA7ih NcIw9obZQNzfcTEiZHjEClxE/lyXHeUhIyuMk0JD5OFM2GgWMIQd2709D1GN1Xc6fQ6j mw== Received: from mx0b-00154901.pphosted.com (mx0b-00154901.pphosted.com [67.231.157.37]) by mx0a-00154904.pphosted.com with ESMTP id 2tymfsw2r3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 26 Jul 2019 16:00:57 -0400 Received: from pps.filterd (m0144103.ppops.net [127.0.0.1]) by mx0b-00154901.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x6QJq4th107840; Fri, 26 Jul 2019 16:00:56 -0400 Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by mx0b-00154901.pphosted.com with ESMTP id 2u0824g3gx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 26 Jul 2019 16:00:56 -0400 Received: from maildlpprd53.lss.emc.com (maildlpprd53.lss.emc.com [10.106.48.157]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x6QK04BK024591 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 26 Jul 2019 16:00:55 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com x6QK04BK024591 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1564171255; bh=ZDgPsM8Yv9kOY6PuSV3JjYsgus4=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=iyEndijyXycJZrrGGe88A6I3/XGYQR7f+L4UmHdDLHlB2zr70g4DMPbYLiKLdUvpY OCcG3CO5D+4YFCWVapbxRl7JvtBAJo++AujDQqfY4mRS2Qk5zPJIVfEptZIEtSZw2l OxGrvGhg4Wz2Qh1Trss3A4LFogJSVZRcAoFzepjE= Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd53.lss.emc.com (RSA Interceptor); Fri, 26 Jul 2019 15:58:15 -0400 Received: from MXHUB310.corp.emc.com (MXHUB310.corp.emc.com [10.146.3.36]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x6QJwEMe009669 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Fri, 26 Jul 2019 15:58:14 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB310.corp.emc.com ([10.146.3.36]) with mapi id 14.03.0439.000; Fri, 26 Jul 2019 15:58:13 -0400 From: "Black, David" To: Sebastian Moeller CC: Bob Briscoe , "ecn-sane@lists.bufferbloat.net" , "tsvwg@ietf.org" , "Dave Taht" , "De Schepper, Koen (Nokia - BE/Antwerp)" , "Black, David" Thread-Topic: [Ecn-sane] [tsvwg] Compatibility with singlw queue RFC3168 AQMs Thread-Index: AQHVQ5u+SJmz/sc6IEGJPXh0k6GQ76bc61mwgABoxAD///g7kA== Date: Fri, 26 Jul 2019 19:58:12 +0000 Message-ID: References: <364514D5-07F2-4388-A2CD-35ED1AE38405@akamai.com> <17B33B39-D25A-432C-9037-3A4835CCC0E1@gmail.com> <52F85CFC-B7CF-4C7A-88B8-AE0879B3CCFE@gmail.com> <87ef2myqzv.fsf@taht.net> <4B02593C-E67F-4587-8B7E-9127D029AED9@gmx.de> <34e3b1b0-3c4c-bb6a-82c1-89ac14d5fd2c@bobbriscoe.net> <77522c07-6f2e-2491-ba0e-cbef62aad194@bobbriscoe.net> <619092c0-640f-56c2-19c9-1cc486180c8b@bobbriscoe.net> <3A454B00-AEBC-48B6-9A8A-922C66E884A7@gmx.de> <21E40F44-2151-4565-970E-E1CEBE975036@gmx.de> <1485F800-CFA5-40D6-8A49-CED09971911C@gmx.de> In-Reply-To: <1485F800-CFA5-40D6-8A49-CED09971911C@gmx.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-07-26T19:42:48.1806617Z; 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.105.8.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-26_14:, , 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-1907260231 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-1907260231 Subject: Re: [Ecn-sane] [tsvwg] Compatibility with singlw queue RFC3168 AQMs X-BeenThere: ecn-sane@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion of explicit congestion notification's impact on the Internet List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2019 20:01:44 -0000 Sebastian, Continuing with the official (officious?) response, in part as the author o= f RFC 8311 ... > Am I correct in interpreting the following sentence from RFC 8311: > "ECN experiments are expected to coexist with deployed ECN > functionality, with the responsibility for that coexistence falling > primarily upon designers of experimental changes to ECN." > as meaning, that L4S will need to implement the long discussed fall-back = to > RFC3168 compliant responses to CE marks, if a RFC3168 AQM is detected as > being active on a path, and that L4S endpoint need to closely monitor for= signs > of RFC3168 behavior? As RFC 8311 is a Proposed Standard RFC, the text quoted from that RFC "repr= esents the consensus of the IETF community" (from "Status of This Memo" boi= lerplate in RFC 8311), and hence needs to be respected in the design of the= L4S experiment. I think the specific implications of that RFC 8311 text o= n the L4S experiment design are ultimately a technical matter for the WG to= determine, but ignoring the quoted text would not be acceptable (and does = not appear to be occurring). Thanks, --David > -----Original Message----- > From: Sebastian Moeller > Sent: Friday, July 26, 2019 12:07 PM > To: Black, David > Cc: Bob Briscoe; ecn-sane@lists.bufferbloat.net; tsvwg@ietf.org; Dave Tah= t; De > Schepper, Koen (Nokia - BE/Antwerp) > Subject: Re: [Ecn-sane] [tsvwg] Compatibility with singlw queue RFC3168 A= QMs >=20 >=20 > [EXTERNAL EMAIL] >=20 > Dear David, >=20 > thanks for your clearing things up. I see, I should have read deeper into= the > relevant "web" of RFCs before asking. >=20 > Am I correct in interpreting the following sentence from RFC 8311: > "ECN experiments are expected to coexist with deployed ECN > functionality, with the responsibility for that coexistence falling > primarily upon designers of experimental changes to ECN." > as meaning, that L4S will need to implement the long discussed fall-back = to > RFC3168 compliant responses to CE marks, if a RFC3168 AQM is detected as > being active on a path, and that L4S endpoint need to closely monitor for= signs > of RFC3168 behavior? I ask because section 4.1 fails to put in those safe= -guard > clauses explicitly (in my reading this effectively says anything goes, as= long as it > is defined in its own RFC) >=20 > Now looking at the L4S RFC I see (https://tools.ietf.org/html/draft-ietf-= tsvwg- > l4s-arch-04#page-21 (assuming that this is one of the RFCs required to al= low the > exemption according to RFC8311)): >=20 > "Classic ECN support is starting to materialize on the Internet as an > increased level of CE marking. Given some of this Classic ECN might > be due to single-queue ECN deployment, an L4S sender will have to > fall back to a classic ('TCP-Friendly') behaviour if it detects that > ECN marking is accompanied by greater queuing delay or greater delay > variation than would be expected with L4S (see Appendix A.1.4 of [I-D.= ietf- > tsvwg-ecn-l4s-id]). > It is hard to detect whether this is > all due to the addition of support for ECN in the Linux > implementation of FQ-CoDel, which would not require fall-back to > Classic behaviour, because FQ inherently forces the throughput of > each flow to be equal irrespective of its aggressiveness." >=20 > Which I believe to be problematic, as it conflates issues. The problem wi= th L4S- > CE response on non L4S-AQMs is that it will give L4S flows an unfair and > unexpected advantage, so L4S endpoints should aim at detecting non-L4S AQ= Ms > on the path and not (just) "that ECN marking is accompanied by greater qu= euing > delay or greater delay variation than would be expected with L4S". Sure d= elay > variations can be a eans of trying to detect such an AQM, but this text b= asically > gives L4S the license to just look at RTT variations and declare victory = if these > stay below an arbitrary threshold. > Also I voiced concerns about the rationale for excluding RFC3168 FQ- > AQMs from this fall-back treatment, and gave an explicit example of a sys= tem in > use (post-true bottleneck ingress shaping) that I would like to see to be= tested > first. This should be easy to test (and as far as I know these tests are = planned if > not already done) so that the RFC can either be amended with a link to th= e data > showing that this is harmless, or changed ot indicate that the fall-back = might > also be required for FQ-AQMs under certain conditions. >=20 >=20 > Now if I look at https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-= 07#page- > 25, I see the following: >=20 > "A.1.4. Fall back to Reno-friendly congestion control on classic ECN bot= tlenecks >=20 > Description: A scalable congestion control needs to react to ECN > marking from a non-L4S but ECN-capable bottleneck in a way that will > coexist with a TCP Reno congestion control [RFC5681]. >=20 > Motivation: Similarly to the requirement in Appendix A.1.3, this > requirement is a safety condition to ensure a scalable congestion > control behaves properly when it builds a queue at a network > bottleneck that has not been upgraded to support L4S. On detecting > classic ECN marking (see below), a scalable congestion control will > need to fall back to classic congestion control behaviour. If it > does not comply with this requirement it could starve classic > traffic. >=20 > It would take time for endpoints to distinguish classic and L4S ECN > marking. An increase in queuing delay or in delay variation would be > a tell-tale sign, but it is not yet clear where a line would be drawn > between the two behaviours. It might be possible to cache what was > learned about the path to help subsequent attempts to detect the type > of marking." >=20 > Here, the special casing of FQ-AQMs does not seem to be present, which L4= S > RFC will have precedence here? >=20 >=20 > Anyway, am I correct in interpreting all of the above as a clear an unamb= iguous > requirement for L4S components like TCP-Prague to implement RFC3168-AQM > detection and fall-back to appropriate behavior before being given the > permission for usage on the wider internet? >=20 >=20 > Best Regards > Sebastian >=20 > > On Jul 26, 2019, at 16:10, Black, David wrote: > > > > Inline comment on "IETF's official stance": > > > >> The first option seems highly undesirable to me, as a) (TCP-friendly) = single > queue > >> RFC3168 AQM are standards compliant and will be for the foreseeable fu= ture, > so > >> ms making them ineffective seems like a no-go to me (could someone cla= rify > >> what the IETF's official stance is on this matter, please?), > > > > The IETF expects that all relevant technical concerns such as this one = will be > raised by participants and will be carefully considered by the WG in dete= rmining > what to do. > > > > That was the technical answer, now for the official [officious? :-) ] a= nswer ... > the current L4S drafts do not modify RFC 3168 beyond the modifications al= ready > made by RFC 8311. If anyone believes that to be incorrect, i.e., believe= s at least > one of the L4S drafts has to further modify RFC 3168, please bring that u= p with a > specific reference to the text in "RFC 3168 as modified by RFC 8311" that= needs > further modification. > > > > Thanks, --David > > > >> -----Original Message----- > >> From: Sebastian Moeller > >> Sent: Friday, July 26, 2019 6:20 AM > >> To: Bob Briscoe > >> Cc: Black, David; ecn-sane@lists.bufferbloat.net; tsvwg@ietf.org; Dave= Taht; > De > >> Schepper, Koen (Nokia - BE/Antwerp) > >> Subject: [Ecn-sane] [tsvwg] Compatibility with singlw queue RFC3168 AQ= Ms > >> > >> > >> [EXTERNAL EMAIL] > >> > >> Dear Bob, > >> > >> we have been going through the consequences and side effects of re-def= ining > >> the meaning of a CE-mark for L4S-flows and using ECT(1) as a flllow- > classifying > >> heuristic. > >> One of the side-effects is that a single queue ecn-enabled AQM will C= E-marl > L4S > >> packets, expecting a strong reduction in sending rate, while the L4S e= ndpoints > >> will only respond to that signal with a mild rate-reduction. One of th= e > >> consequences of this behaviour is that L4S flows will crowd out RFC316= 8 and > >> non-ECN flows, because these flows half their rates on drop or CE-mark > >> (approximately) making congestion go away with the end result that the= L4S > >> flows gain an undesired advantage, at least that is my interpretation = of the > >> discussion so far. > >> Now there are two options to deal with this issue, one is to declare i= t > >> insignificant and just ignore it, or to make L4S endpoints detect that= condition > >> and revert back to RFC3168 behaviour. > >> The first option seems highly undesirable to me, as a) (TCP-friendly) = single > queue > >> RFC3168 AQM are standards compliant and will be for the foreseeable fu= ture, > so > >> ms making them ineffective seems like a no-go to me (could someone cla= rify > >> what the IETF's official stance is on this matter, please?), b) I woul= d expect > most > >> of such AQMs to be instantiated close to/at the consu,er's edge of the > internet, > >> making it really hard to ameasure their prevalence. > >> In short, I believe the only sane way forward is to teach L4S endpoint= s to to > the > >> right thing under such conditions, I believe this would not be too one= rous an > ask, > >> given that the configuration is easy to set up for testing and develop= ment and > a > >> number of ideas have already been theoretically discussed here. As far= as I > can > >> see these ideas mostly riff on the idea that such anAQM will, under > congesation > >> conditions, increase each ftraversing flow's RTT and that should be qu= ickly > and > >> robustly detectable. I would love to learn more about these ideas and = the > state > >> of development and testing. > >> > >> Best Regards & many thanks in advance > >> Sebastian Moeller