[tsvwg] ECN-Dualq-SCE as a documented option in l4s-id?
"Holland, Jake" <jholland@akamai.com> Mon, 17 February 2020 23:27 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 D0A7412086C for <tsvwg@ietfa.amsl.com>; Mon, 17 Feb 2020 15:27:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 Pr21ymSYa6Hx for <tsvwg@ietfa.amsl.com>; Mon, 17 Feb 2020 15:27:05 -0800 (PST)
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 9D9F412085E for <tsvwg@ietf.org>; Mon, 17 Feb 2020 15:27:05 -0800 (PST)
Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 01HNR5GU002722 for <tsvwg@ietf.org>; Mon, 17 Feb 2020 23:27:05 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=kywTSOGZA3/GuPt/0Hwr6h8SWXHa7bTibJS6q5fb+dA=; b=NgbrORfLf3RRnoz7OjnBzR3BN4LYy/GllnFhBgIH5TrnFYQiBVckhqurn+SrM/GnvP2M 7OgQGhXF/gVAxZ39ZOaKCNaVL+MNSv+PsEHgDxIlaMh5eH+spT8H2/4IcjkPdh3ir2RM gGAqqd5FbWqUXh/00i/6vTrlnJUAIUv0Eig4X1/cES+TM4utzC32lgAe8So1gR+QZ4vo 8x+3cwZGTbvfHgnAxA+ovJdqGfoTIZ94AENTiDj0lxAzBrw/2n4PsaKQhVIHyUpqvTf4 nGxsnSM0FEfVjO9BvoL7lWgtzGzoY20yGX3q5i6RIJZSJZORY9lPBUfZrwm+7usLTIIY Gg==
Received: from prod-mail-ppoint8 (prod-mail-ppoint8.akamai.com [96.6.114.122] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2y69jqstdg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <tsvwg@ietf.org>; Mon, 17 Feb 2020 23:27:05 +0000
Received: from pps.filterd (prod-mail-ppoint8.akamai.com [127.0.0.1]) by prod-mail-ppoint8.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 01HNHl6K024506 for <tsvwg@ietf.org>; Mon, 17 Feb 2020 18:27:03 -0500
Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint8.akamai.com with ESMTP id 2y6cv2sj6n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for <tsvwg@ietf.org>; Mon, 17 Feb 2020 18:27:03 -0500
Received: from usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 17 Feb 2020 18:27:02 -0500
Received: from usma1ex-dag1mb6.msg.corp.akamai.com ([172.27.123.65]) by usma1ex-dag1mb6.msg.corp.akamai.com ([172.27.123.65]) with mapi id 15.00.1473.005; Mon, 17 Feb 2020 18:27:02 -0500
From: "Holland, Jake" <jholland@akamai.com>
To: "tsvwg@ietf.org" <tsvwg@ietf.org>
Thread-Topic: ECN-Dualq-SCE as a documented option in l4s-id?
Thread-Index: AQHV5enChnlDAmAMy06XxZ3HpATmbA==
Date: Mon, 17 Feb 2020 23:27:02 +0000
Message-ID: <A213838F-B051-4D43-82F9-A1AC55769B01@akamai.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.22.0.200209
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.80.24]
Content-Type: text/plain; charset="utf-8"
Content-ID: <B3E932EAC58F5943A9100B122C9AC573@akamai.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-02-17_14:, , 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-2002050000 definitions=main-2002170191
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-02-17_14:2020-02-17, 2020-02-17 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 priorityscore=1501 suspectscore=0 impostorscore=0 bulkscore=0 clxscore=1011 phishscore=0 spamscore=0 lowpriorityscore=0 malwarescore=0 mlxscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2002170192
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/Rqnbg68MSH8f07_DyL1N0qMzPjE>
Subject: [tsvwg] ECN-Dualq-SCE as a documented option in l4s-id?
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: Mon, 17 Feb 2020 23:27:08 -0000
Hi Bob, Koen, and tsvwg, I'd like to request adding the ECN-DualQ-SCE proposal to the list of alternative options considered for the dualq classifier, in Appendix B of l4s-id [0]. To slightly flesh out what I'm asking for: The proposal I'd like to see added is to use a state-based classifier for the dualq that uses a per-flow measure of sparseness in addition to ECT to classify packets into the low-latency queue, so that when flows do not maintain the sparseness expected of L4S-compatible flows, their packets go to the classic queue. Some notes that may help when considering and/or implementing this request, with some [numbered-references] at the bottom. 1. As I understand it, ECN-DualQ-SCE compromises on the "SHOULD be visible at the IP layer" criteria from section 2 of l4s-id, and gains some ground (sort of) on "SHOULD consume minimal extra codepoints". But maybe more importantly, it comes with some other tradeoffs that might be worth covering as similar "SHOULD" requirements in section 2. For instance, maybe the section 2 criteria for the ideal yet unachievable l4s-id identifier should mention "SHOULD allow for unambiguous congestion signaling to distinguish the LL 1/p congestion signal from the classic 1/sqrt(p) signal". This would point out more explicitly an important compromise the ECT(1) approach makes. (By listing it this way, I suspect it can more easily be made clear that the requirement for a complex classic queue detection algorithm is a workaround that provides a mitigation for compromising on this point under the ECT(1) approach, but could be a much more trivial "received CE" check under ECN-DualQ-SCE.). I'll also note this approach would provide a simple answer to the admission control questions, which may also be worth a mention in the doc. I think adding such a section would make it more clear in the document text what the nature of the tradeoffs are between these approaches, so the working group can more easily make an informed consensus decision. 2. I was reviewing some of the earlier discussion on ECN-DualQ-SCE [1][2][3][4]. On reflection, it seems to me it's a mistaken claim that SCE is unsuitable for anything other than strict FQ, and much of the previous discussion rested on that (I think) mistaken claim. I noticed basically because Koen pointed out that CNQ was behaving like a dualq, during a side discussion at Singapore when Jonathan was explaining how CNQ worked (and pointing out that it does not enforce flow rate fairness in any remotely strict sense), and his observation stuck with me. In light of this observation, it seems to me the ECN-DualQ-SCE concept is at least as worthwhile a possibility to mention as the other sections in Appendix B, and that it's especially relevant to get the issues documented as an integrated part of the l4s-id draft while issue #20 is under discussion [6]. However, even if this turns out to be mistaken on closer examination, I'd still like the proposal added to l4s-id's list of classifier options, perhaps along with a walkthrough of the reasoning for the arguments against adopting it, with maybe pointers to the relevant publications that looked into it. 3. I think under ECN-DualQ-SCE, "measure of flow sparseness" is a pretty wide design space, as we're seeing from some of the SCE-related work. (So much so that I imagine this as one of the reasonable points against adopting it...). But I think, as Koen pointed out, CNQ seems to qualify as an example of one approach that has an implementation (though the existing implementation may not satisfy all the rest of the dualq requirements, I'd guess). But as mentioned above, from what I hear CNQ doesn't have the strict-flow-rate-fairness issue that you've objected to in [3] and [5]. It also seems that the queue protection mechanism in the DOCSIS 3.1 MAC spec (Annex P) would qualify as a state-based classifier that's based on a measurement of flow sparseness? So I'd assume that at least some level of flow-related additional complexity in a dualq must be considered feasible? (Or maybe feasible with mostly-untested performance? I recall you saying you looked into this some years ago--if you have it, it might be helpful to get a pointer to the results showing the effect of competing classic traffic on low-latency traffic with just ECT as classifier when a docsis-style queue protection mechanism is in place, if there's anything like that somewhere? I didn't see where the prior research was written up.) 4. My motivation is that I am still concerned about the ambiguous signaling in the ECT(1) approach and its potential consequences, so I'd like at least to see the discussion of the best available classification strategy cover the ECN-DualQ-SCE option, for the benefit of the working group's review of the decision. 5. I'll also note that adding this doesn't require an SCE reference, because I think you can point to what seems to be a roughly equivalent CE(0)/CE(1) option mentioned in section 20.2 of RFC 3168. Thanks for considering this request. Best regards, Jake References: [0] https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-08#appendix-B [1] An early suggestion to combine L4S with SCE's signaling: https://mailarchive.ietf.org/arch/msg/tsvwg/WYNurfs72tf-y-hrGHzEazg1qcI [2] Bob's response, with a medium-detailed reasoning chain for dismissing it: https://mailarchive.ietf.org/arch/msg/tsvwg/nzQiSwYtDC7rFKDzhXbt5velfa0 [3] Bob's bigger, academically formatted response about FQ generally: http://bobbriscoe.net/projects/latency/per-flow_tr.pdf [4] A place I agreed that SCE requires FQ: https://mailarchive.ietf.org/arch/msg/tsvwg/QjuQbNpW9zCbJpdLxsdPTAb1oME I'm retracting the statement (or if you prefer, pointing out that even the original came with qualifiers like "rough" and "with caveats"). I now think we were talking past each other, and that although I agree there is some per-flow state necessary to get latency benefits from SCE, this is different from the strict FQ that Bob's paper objects to. (At the time, I was thinking of this as "roughly FQ", but I now think it's materially different from FQ as Bob's paper describes it, based on descriptions given there.) [5] The cited "Dismantling a Religion" paper: https://web.stanford.edu/class/cs244/papers/fair-ccr2007.pdf [6] Objection to ECT(1) codepoint usage https://trac.ietf.org/trac/tsvwg/ticket/20
- [tsvwg] ECN-Dualq-SCE as a documented option in l… Holland, Jake
- Re: [tsvwg] ECN-Dualq-SCE as a documented option … Bob Briscoe
- Re: [tsvwg] ECN-Dualq-SCE as a documented option … Holland, Jake
- Re: [tsvwg] ECN-Dualq-SCE as a documented option … Bob Briscoe
- Re: [tsvwg] ECN-Dualq-SCE as a documented option … Holland, Jake