Re: [tsvwg] [Ecn-sane] Compatibility with singlw queue RFC3168 AQMs

"Black, David" <David.Black@dell.com> Fri, 26 July 2019 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 A69B7120052 for <tsvwg@ietfa.amsl.com>; Fri, 26 Jul 2019 13:09:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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, 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=TrjygBIF; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=GYkUB7Oq
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 5m_9M_BOGKmO for <tsvwg@ietfa.amsl.com>; Fri, 26 Jul 2019 13:09:09 -0700 (PDT)
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 47F59120047 for <tsvwg@ietf.org>; Fri, 26 Jul 2019 13:09:09 -0700 (PDT)
Received: from pps.filterd (m0170396.ppops.net [127.0.0.1]) by mx0b-00154904.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x6QJlDY2019447; Fri, 26 Jul 2019 16:08:21 -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=lFAGjTSaDVVkoAlNIofxTCYfjal/MB62aBoNuBHymH0=; b=TrjygBIFJ905WbAz7U5toxa5HVgvf3e7HlVnvn0d6LbOPUlOjRe02ztch8Rx8psKQXJK 2kmUK03MGy7+HjFxmJdZSib/MDNlr43mybPEcMMBwrsHUN034fgnGgilbzCiVz3A172y lZn0qhf/O+i1asPv/6KoZa0NKJ+qH7t+68EpIDIWsF7xmm/uEMCcZZvuW7WKK7D8TUBc BFhL5XAyHR2VPDmB7VNTm1+ktF4S0N67LIu8eW6Yo+xI0gzTbAdSn4/j3i1lC9/7Z+cz 846QsRKA3gQ+ABOc+TpKt5PMya41GpJnxlMce2HRHVmdwa5TVxgeLeC45jFsQcglQHch xg==
Received: from mx0b-00154901.pphosted.com (mx0a-00154901.pphosted.com [67.231.149.39]) by mx0b-00154904.pphosted.com with ESMTP id 2u07yxg2jq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 26 Jul 2019 16:08:21 -0400
Received: from pps.filterd (m0090350.ppops.net [127.0.0.1]) by mx0b-00154901.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x6QK8JFw093693; Fri, 26 Jul 2019 16:08:20 -0400
Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by mx0b-00154901.pphosted.com with ESMTP id 2u05qvj747-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 26 Jul 2019 16:08:20 -0400
Received: from maildlpprd01.lss.emc.com (maildlpprd01.lss.emc.com [10.253.24.33]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x6QK7ST0000850 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 26 Jul 2019 16:07:42 -0400
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com x6QK7ST0000850
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1564171662; bh=IotJSfeY07c2oJqvsNzwE9fErgg=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=GYkUB7OqslBEDC2JXGCV9Kn8tQ4KrU3LYI5hxB0i5IRfMiPjZHvHKlAGHwlupC2OZ pbHAbQoZjHIr2triIDEa+duKH3K6LBjOWWn1M+T6K4aNXeJv98aAaip8H4P6GQWPDU T+OlZeR8BqiCSncomxJX5sddJnRwzLFbrBv7t9kk=
Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd01.lss.emc.com (RSA Interceptor); Fri, 26 Jul 2019 16:07:04 -0400
Received: from MXHUB301.corp.emc.com (MXHUB301.corp.emc.com [10.146.3.27]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x6QK73kb016001 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Fri, 26 Jul 2019 16:07:03 -0400
Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB301.corp.emc.com ([10.146.3.27]) with mapi id 14.03.0439.000; Fri, 26 Jul 2019 16:07:03 -0400
From: "Black, David" <David.Black@dell.com>
To: "Holland, Jake" <jholland@akamai.com>, Sebastian Moeller <moeller0@gmx.de>, Bob Briscoe <ietf@bobbriscoe.net>
CC: "De Schepper, Koen (Nokia - BE/Antwerp)" <koen.de_schepper@nokia-bell-labs.com>, "ecn-sane@lists.bufferbloat.net" <ecn-sane@lists.bufferbloat.net>, "tsvwg@ietf.org" <tsvwg@ietf.org>, Dave Taht <dave@taht.net>, "Black, David" <David.Black@dell.com>
Thread-Topic: [Ecn-sane] [tsvwg] Compatibility with singlw queue RFC3168 AQMs
Thread-Index: AQHVQ5u+SJmz/sc6IEGJPXh0k6GQ76bc61mwgABrQYD///wgkA==
Date: Fri, 26 Jul 2019 20:07:02 +0000
Message-ID: <CE03DB3D7B45C245BCA0D2432779493630640036@MX307CL04.corp.emc.com>
References: <364514D5-07F2-4388-A2CD-35ED1AE38405@akamai.com> <17B33B39-D25A-432C-9037-3A4835CCC0E1@gmail.com> <AM4PR07MB345956F52D92759F24FFAA13B9F50@AM4PR07MB3459.eurprd07.prod.outlook.com> <52F85CFC-B7CF-4C7A-88B8-AE0879B3CCFE@gmail.com> <AM4PR07MB3459B471C4D7ADAE4CF713F3B9F60@AM4PR07MB3459.eurprd07.prod.outlook.com> <D231681B-1E57-44E1-992A-E8CC423926B6@akamai.com> <AM4PR07MB34592A10E2625C2C32B9893EB9F00@AM4PR07MB3459.eurprd07.prod.outlook.com> <A6F05DD3-D276-4893-9B15-F48E3018A129@gmx.de> <AM4PR07MB3459487C8A79B1152E132CE1B9CB0@AM4PR07MB3459.eurprd07.prod.outlook.com> <87ef2myqzv.fsf@taht.net> <a85d38ba-98ac-e43e-7610-658f4d03e0f4@mti-systems.com> <CE03DB3D7B45C245BCA0D243277949363062879C@MX307CL04.corp.emc.com> <e1660988-3651-0c3b-cdc1-5518f067e42e@bobbriscoe.net> <4B02593C-E67F-4587-8B7E-9127D029AED9@gmx.de> <34e3b1b0-3c4c-bb6a-82c1-89ac14d5fd2c@bobbriscoe.net> <E031B993-DAAF-4BE4-A542-33C44310D6E9@gmx.de> <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> <CE03DB3D7B45C245BCA0D243277949363063EA1C@MX307CL04.corp.emc.com> <58F8052E-A56B-4E1F-8E1D-CBE75A0F7332@akamai.com>
In-Reply-To: <58F8052E-A56B-4E1F-8E1D-CBE75A0F7332@akamai.com>
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="utf-8"
Content-Transfer-Encoding: base64
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-1907260232
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
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/LGIteUVbXr7YGmOQOEQLcZHhZeo>
Subject: Re: [tsvwg] [Ecn-sane] Compatibility with singlw queue RFC3168 AQMs
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: Fri, 26 Jul 2019 20:09:12 -0000

Jake,

> I believe under this nomenclature, L4S in a queue with RFC3168-style
> marking at a bottleneck should be classified as a flow that is
> responsive but not TCP-compatible, and therefore poses a significant
> threat to internet performance within this context.
> 
> I'm not sure how best to describe this discrepancy, but I think it's
> fair to call it an incompatibility between a RFC3168-style marking
> queue and L4S.

Based on the L4S slides in today's meeting and related discussion, the L4S folks are starting to deal with this concern.

I share your technical view that this concern is not safe to ignore.

Thanks, --David

> -----Original Message-----
> From: Holland, Jake <jholland@akamai.com>
> Sent: Friday, July 26, 2019 12:16 PM
> To: Black, David; Sebastian Moeller; Bob Briscoe
> Cc: De Schepper, Koen (Nokia - BE/Antwerp); ecn-sane@lists.bufferbloat.net;
> tsvwg@ietf.org; Dave Taht
> Subject: Re: [Ecn-sane] [tsvwg] Compatibility with singlw queue RFC3168 AQMs
> 
> 
> [EXTERNAL EMAIL]
> 
> On 2019-07-26, 10:13, "Black, David" <David.Black@dell.com> wrote:
> >> 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 future,
> so
> >> ms making them ineffective seems like a no-go to me (could someone clarify
> >> 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 determining
> what to do.
> >
> > That was the technical answer, now for the official [officious? :-) ] answer ...
> the current L4S drafts do not modify RFC 3168 beyond the modifications 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, please bring that up with a
> specific reference to the text in "RFC 3168 as modified by RFC 8311" that needs
> further modification.
> 
> I'll try pointing to some specific citations.  I think there may be
> others along these lines, and would love to see a more complete
> enumeration, but in the interest of a timely response, thought I'd
> send one of the first I saw.
> 
> I'm not sure how I could recommend updating RFC 3168 to address this
> point, but I do believe it's an incompatibility between the L4S
> proposal and RFC 3168.
> 
> 
> From https://tools.ietf.org/html/rfc8311#section-2.1
> 2.1.  Effective Congestion Control is Required
> 
>    Congestion control remains an important aspect of the Internet
>    architecture [RFC2914].  Any Experimental RFC in the IETF document
>    stream that takes advantage of this memo's updates to any RFC is
>    required to discuss the congestion control implications of the
>    experiment(s) in order to provide assurance that deployment of the
>    experiment(s) does not pose a congestion-based threat to the
>    operation of the Internet.
> 
> 
> From https://tools.ietf.org/html/rfc2914#section-3.2
> 3.2.  Fairness
> ...
>    It is convenient to divide flows into three classes: (1) TCP-
>    compatible flows, (2) unresponsive flows, i.e., flows that do not
>    slow down when congestion occurs, and (3) flows that are responsive
>    but are not TCP-compatible.  The last two classes contain more
>    aggressive flows that pose significant threats to Internet
>    performance, as we discuss below.
> 
> 
> I believe under this nomenclature, L4S in a queue with RFC3168-style
> marking at a bottleneck should be classified as a flow that is
> responsive but not TCP-compatible, and therefore poses a significant
> threat to internet performance within this context.
> 
> I'm not sure how best to describe this discrepancy, but I think it's
> fair to call it an incompatibility between a RFC3168-style marking
> queue and L4S.
> 
> I didn't see this explicitly discussed in the L4S drafts as an
> incompatibility that proposes to deploy a threat to flows in RFC3168
> queues, but to me it seems required by RFC 8311 (and possibly in
> conflict with the advice from section 4 of BCP 197, recommending the
> use of ECN in deployed AQM devices).
> 
> On the contrary, I think we saw this described on the list as a non-
> problem because most of the live RFC 3168 queues that we know about
> are FQ (with the implication that this is sufficient to protect against
> the non-TCP-compatible flows, except where there's a hash collision).
> 
> To me it seems unsafe to deploy this experiment without deprecating
> the BCP 197 advice, and the root cause is its interaction with RFC
> 3168 marking.
> 
> Something like a requirement for a controlled environment would
> address this problem, to me, and of course perhaps I'm on the rough
> side of the consensus, but I think worth calling out the issue for
> open discussion.
> 
> Best regards,
> Jake
>