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 DD1013CB37 for ; Fri, 26 Jul 2019 10:13:02 -0400 (EDT) Received: from pps.filterd (m0170389.ppops.net [127.0.0.1]) by mx0a-00154904.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x6QE9s4D028352; Fri, 26 Jul 2019 10:12:14 -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=FcSTQvgttS37Ikdrx6s0qeBudT9mkXQf6epig0fvm9M=; b=lOAIbEiGa56jM59Sp19BzmCcqDNB4IYgl4fYiUqWlweW3OCzkD3wK5gqB+lhhghPycLt jqxk5xHKbf8a2F8KWdI2g8v2f6sZDsPTSH+cJhypsV02RP3OHncXb7OeEG50lkrKE0TS MNqw8HQMqMlIc8KEdBJD9cpdxifUEIxbOaPit/4onviFDk12gTbsXqPttd7XuqIRbbai busNOJ061XAhHC0k99s7xfu6VMEyhPIahEzqIVVQUxMo9ffT48Q8A5Nm7vheN59aNJ16 PnmpklFw3ZF5LFe5iTrN7GBLk/06vK1uob8pRA4QnL6uAD8/UpupxualDlAqntC53hbr sg== Received: from mx0b-00154901.pphosted.com (mx0b-00154901.pphosted.com [67.231.157.37]) by mx0a-00154904.pphosted.com with ESMTP id 2tymfskhaf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 26 Jul 2019 10:12:14 -0400 Received: from pps.filterd (m0144104.ppops.net [127.0.0.1]) by mx0b-00154901.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x6QE7phl133453; Fri, 26 Jul 2019 10:12:13 -0400 Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by mx0b-00154901.pphosted.com with ESMTP id 2tyybdbr3u-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 26 Jul 2019 10:12:13 -0400 Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x6QEBofZ008171 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 26 Jul 2019 10:12:12 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com x6QEBofZ008171 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1564150332; bh=ZawJdwIoXMtUXVikJIa7pAR2IQo=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=EcloW3j29DtwLfL3I+KrdAdAPaMKWfHT6JHdLiZdFqRaXHRt6rmvpAe7omEPi3BMR BnR7AGSxjdgjhc53c1pL4LTb58T7g2O3huJ6W7Fb3owvue2j9ccvY57NSioA3yBFZB imB9pCTUmx9QsPCip/RJg9TBUJGKDz414E/Tfhbc= Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd06.lss.emc.com (RSA Interceptor); Fri, 26 Jul 2019 10:10:51 -0400 Received: from MXHUB321.corp.emc.com (MXHUB321.corp.emc.com [10.146.3.99]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x6QEApSW029868 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Fri, 26 Jul 2019 10:10:52 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB321.corp.emc.com ([10.146.3.99]) with mapi id 14.03.0439.000; Fri, 26 Jul 2019 10:10:51 -0400 From: "Black, David" To: Sebastian Moeller , Bob Briscoe CC: "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/sc6IEGJPXh0k6GQ76bc61mw Date: Fri, 26 Jul 2019 14:10:50 +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> In-Reply-To: <21E40F44-2151-4565-970E-E1CEBE975036@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-26T13:51:56.5242037Z; 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_10:, , 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=1011 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-1907260173 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 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-1907260174 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 14:13:03 -0000 Inline comment on "IETF's official stance": > The first option seems highly undesirable to me, as a) (TCP-friendly) sin= gle queue > RFC3168 AQM are standards compliant and will be for the foreseeable futur= e, so > ms making them ineffective seems like a no-go to me (could someone clarif= y > 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 de= termining what to do. That was the technical answer, now for the official [officious? :-) ] answe= r ... the current L4S drafts do not modify RFC 3168 beyond the modification= s already made by RFC 8311. If anyone believes that to be incorrect, i.e.,= believes at least one of the L4S drafts has to further modify RFC 3168, pl= ease bring that up with a specific reference to the text in "RFC 3168 as mo= dified 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 Ta= ht; De > Schepper, Koen (Nokia - BE/Antwerp) > Subject: [Ecn-sane] [tsvwg] Compatibility with singlw queue RFC3168 AQMs >=20 >=20 > [EXTERNAL EMAIL] >=20 > Dear Bob, >=20 > we have been going through the consequences and side effects of re-defini= ng > the meaning of a CE-mark for L4S-flows and using ECT(1) as a flllow-class= ifying > heuristic. > One of the side-effects is that a single queue ecn-enabled AQM will CE-m= arl L4S > packets, expecting a strong reduction in sending rate, while the L4S endp= oints > will only respond to that signal with a mild rate-reduction. One of the > consequences of this behaviour is that L4S flows will crowd out RFC3168 a= nd > 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 L4= S > 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 it > insignificant and just ignore it, or to make L4S endpoints detect that co= ndition > and revert back to RFC3168 behaviour. > The first option seems highly undesirable to me, as a) (TCP-friendly) sin= gle queue > RFC3168 AQM are standards compliant and will be for the foreseeable futur= e, so > ms making them ineffective seems like a no-go to me (could someone clarif= y > what the IETF's official stance is on this matter, please?), b) I would e= xpect most > of such AQMs to be instantiated close to/at the consu,er's edge of the in= ternet, > making it really hard to ameasure their prevalence. > In short, I believe the only sane way forward is to teach L4S endpoints t= o to the > right thing under such conditions, I believe this would not be too onerou= s an ask, > given that the configuration is easy to set up for testing and developmen= t 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 conge= sation > conditions, increase each ftraversing flow's RTT and that should be quick= ly and > robustly detectable. I would love to learn more about these ideas and the= state > of development and testing. >=20 > Best Regards & many thanks in advance > Sebastian Moeller