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

"Black, David" <David.Black@dell.com> Fri, 26 July 2019 20:01 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 22294120179 for <tsvwg@ietfa.amsl.com>; Fri, 26 Jul 2019 13:01:47 -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=N3X+HWDG; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=iyEndijy
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 hRdGA0Q468RM for <tsvwg@ietfa.amsl.com>; Fri, 26 Jul 2019 13:01:43 -0700 (PDT)
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 ietfa.amsl.com (Postfix) with ESMTPS id A4E28120047 for <tsvwg@ietf.org>; Fri, 26 Jul 2019 13:01:43 -0700 (PDT)
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" <David.Black@dell.com>
To: Sebastian Moeller <moeller0@gmx.de>
CC: Bob Briscoe <ietf@bobbriscoe.net>, "ecn-sane@lists.bufferbloat.net" <ecn-sane@lists.bufferbloat.net>, "tsvwg@ietf.org" <tsvwg@ietf.org>, "Dave Taht" <dave@taht.net>, "De Schepper, Koen (Nokia - BE/Antwerp)" <koen.de_schepper@nokia-bell-labs.com>, "Black, David" <David.Black@dell.com>
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: <CE03DB3D7B45C245BCA0D243277949363064000A@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> <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
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/jy1WLOUwilOJYlK8vg6egFQkB18>
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:01:47 -0000

Sebastian,

Continuing with the official (officious?) response, in part as the author of 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 "represents the consensus of the IETF community" (from "Status of This Memo" boilerplate 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 on 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 <moeller0@gmx.de>
> Sent: Friday, July 26, 2019 12:07 PM
> To: Black, David
> Cc: Bob Briscoe; ecn-sane@lists.bufferbloat.net; tsvwg@ietf.org; Dave Taht; De
> Schepper, Koen (Nokia - BE/Antwerp)
> Subject: Re: [Ecn-sane] [tsvwg] Compatibility with singlw queue RFC3168 AQMs
> 
> 
> [EXTERNAL EMAIL]
> 
> Dear David,
> 
> thanks for your clearing things up. I see, I should have read deeper into the
> relevant "web" of RFCs before asking.
> 
> 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)
> 
> 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 allow the
> exemption according to RFC8311)):
> 
> "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."
> 
> Which I believe to be problematic, as it conflates issues. The problem with 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 AQMs
> on the path and not (just) "that ECN marking is accompanied by greater queuing
> delay or greater delay variation than would be expected with L4S". Sure delay
> variations can be a eans of trying to detect such an AQM, but this text basically
> 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 system 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 the data
> showing that this is harmless, or changed ot indicate that the fall-back might
> also be required for FQ-AQMs under certain conditions.
> 
> 
> Now if I look at https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-07#page-
> 25, I see the following:
> 
> "A.1.4.  Fall back to Reno-friendly congestion control on classic ECN bottlenecks
> 
>    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].
> 
>    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.
> 
>    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."
> 
> Here, the special casing of FQ-AQMs does not seem to be present, which L4S
> RFC will have precedence here?
> 
> 
> Anyway, am I correct in interpreting all of the above as a clear an unambiguous
> 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?
> 
> 
> Best Regards
> 	Sebastian
> 
> > On Jul 26, 2019, at 16:10, Black, David <David.Black@dell.com> 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 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.
> >
> > Thanks, --David
> >
> >> -----Original Message-----
> >> From: Sebastian Moeller <moeller0@gmx.de>
> >> 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 AQMs
> >>
> >>
> >> [EXTERNAL EMAIL]
> >>
> >> Dear Bob,
> >>
> >> we have been going through the consequences and side effects of re-defining
> >> 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 CE-marl
> L4S
> >> packets, expecting a strong reduction in sending rate, while the L4S endpoints
> >> 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 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 it
> >> 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 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?), b) I would 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 endpoints to to
> the
> >> right thing under such conditions, I believe this would not be too onerous an
> ask,
> >> given that the configuration is easy to set up for testing and development 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 quickly
> 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