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

"Holland, Jake" <jholland@akamai.com> Fri, 26 July 2019 16:16 UTC

Return-Path: <jholland@akamai.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 28A0B120041 for <tsvwg@ietfa.amsl.com>; Fri, 26 Jul 2019 09:16:43 -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=akamai.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 6_ncrHtiTsM1 for <tsvwg@ietfa.amsl.com>; Fri, 26 Jul 2019 09:16:41 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 4FE7212003E for <tsvwg@ietf.org>; Fri, 26 Jul 2019 09:16:41 -0700 (PDT)
Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id x6QG7s9Q009872; Fri, 26 Jul 2019 17:15:52 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=fN01kpzQrqkRHBlBhaL8Q3Zs5roFyy6gv/lu858FDc0=; b=gJS/ndUc2hys3aqwKrfY4MiBe2LZdm6YHGsFXSc1ocfR7n9Lncs2rJ9Oxw7lDsUqzSU+ sNQd18IWXaxhWCQjss+qAH6b9a5yP/au9D7IQfs2qBL+iLokagSFJJmNFTnfLCcQDwiF S8hxe6X/ztwJPcGQerCEvz1RlS4OQ2zNL50v4KKXuA3Zh12UfPRAuFOqHgSWpctVpXtG 83rZVFk5H48D1tO1ADza7o/W3YrvPmu3xaeMi2PC594nz9d4toaTPc1ejO1SKbIXA+rA 8f/SDwDWmm65WPIJRpEk77V92ScUMoRWFv9foqmsTR+0kFY7xwMMYHyP24u/5Wsi63rV hg==
Received: from prod-mail-ppoint4 (prod-mail-ppoint4.akamai.com [96.6.114.87] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2tx60tdc39-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 26 Jul 2019 17:15:52 +0100
Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x6QG31nc005550; Fri, 26 Jul 2019 12:15:51 -0400
Received: from email.msg.corp.akamai.com ([172.27.25.30]) by prod-mail-ppoint4.akamai.com with ESMTP id 2tx632aqq9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 26 Jul 2019 12:15:50 -0400
Received: from USTX2EX-DAG1MB4.msg.corp.akamai.com (172.27.27.104) by ustx2ex-dag1mb5.msg.corp.akamai.com (172.27.27.105) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 26 Jul 2019 11:15:49 -0500
Received: from USTX2EX-DAG1MB4.msg.corp.akamai.com ([172.27.6.134]) by ustx2ex-dag1mb4.msg.corp.akamai.com ([172.27.6.134]) with mapi id 15.00.1473.005; Fri, 26 Jul 2019 11:15:49 -0500
From: "Holland, Jake" <jholland@akamai.com>
To: "Black, David" <David.Black@dell.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>
Thread-Topic: [Ecn-sane] [tsvwg] Compatibility with singlw queue RFC3168 AQMs
Thread-Index: AQHVQ7xBKtEJQ6j/1kmhc26HUTkxBqbc8IyA
Date: Fri, 26 Jul 2019 16:15:47 +0000
Message-ID: <58F8052E-A56B-4E1F-8E1D-CBE75A0F7332@akamai.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>
In-Reply-To: <CE03DB3D7B45C245BCA0D243277949363063EA1C@MX307CL04.corp.emc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1a.0.190609
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-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.36.104]
Content-Type: text/plain; charset="utf-8"
Content-ID: <D69A8F7305D4F54B99C5DD09EC2C3793@akamai.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-26_12:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1907260195
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:5.22.84,1.0.8 definitions=2019-07-26_12:2019-07-26,2019-07-26 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 phishscore=0 spamscore=0 adultscore=0 lowpriorityscore=0 impostorscore=0 priorityscore=1501 mlxlogscore=999 bulkscore=0 clxscore=1011 mlxscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1906280000 definitions=main-1907260196
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/9eUd_KdaDj_UFTamN6y6_O3wyfg>
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 16:16:43 -0000

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