[tcpPrague] ecn-l4s-id: Proposed Changed to Normative Classic ECN detection Text

Bob Briscoe <ietf@bobbriscoe.net> Sat, 31 October 2020 09:54 UTC

Return-Path: <ietf@bobbriscoe.net>
X-Original-To: tcpprague@ietfa.amsl.com
Delivered-To: tcpprague@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 8A6413A17B7; Sat, 31 Oct 2020 02:54:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_FAIL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id i4_zVBObRtje; Sat, 31 Oct 2020 02:54:29 -0700 (PDT)
Received: from cl3.bcs-hosting.net (cl3.bcs-hosting.net []) (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 72FF63A17B6; Sat, 31 Oct 2020 02:54:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:MIME-Version:Date:Message-ID:Cc: To:Subject:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=eYKq+VwUEgnW71/T97TQMHOd2A+89tG4e587FYQWBXI=; b=jP+Pi5IN3eQGD5ErfWA4KXgBzP q/s49toYlkgUW4fxlmN13wjbMPX4EBP4K2INd7b9tElHAC5T4uWwAXdqHi3Tr/rGW97py8eo8sd7u +mRwy3tMHzO9h+bAddUtXUXFshuxGmCOJEYNBFzp62FQaw9Pms/vm8hNnbrkdgoUyM17628PRNXi2 9HuAzfbSEgELTEIQ6s+w03zD8WqLqEjl2xxAuCPkdRqh3oMqAdntg93N9bYz92nSef+FKSrq4vteO ZWzsYlCbH2F2Yt/FSlIObT3F0wZZk4VzTwf0YJjwP40F3ILxDifncakxEsG5vVJgGECeE/xsNcyGK n2Hj7uLQ==;
Received: from ([]:60906 helo=[]) by cl3.bcs-hosting.net with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from <ietf@bobbriscoe.net>) id 1kYnad-00F7Iz-ML; Sat, 31 Oct 2020 09:54:27 +0000
From: Bob Briscoe <ietf@bobbriscoe.net>
To: tsvwg IETF list <tsvwg@ietf.org>
Cc: TCP Prague List <tcpPrague@ietf.org>, iccrg IRTF list <iccrg@irtf.org>, "De Schepper, Koen (Koen)" <koen.de_schepper@nokia.com>
Message-ID: <1b71a610-75ea-e1d4-e3ce-f0ae6a4c12f7@bobbriscoe.net>
Date: Sat, 31 Oct 2020 09:54:26 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------729C9A47D891A9397EB61EE2"
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - cl3.bcs-hosting.net
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: cl3.bcs-hosting.net: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: cl3.bcs-hosting.net: in@bobbriscoe.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpprague/E6R05LyIL5eZAcWb-m0gDlHp7iA>
Subject: [tcpPrague] ecn-l4s-id: Proposed Changed to Normative Classic ECN detection Text
X-BeenThere: tcpprague@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." <tcpprague.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpprague>, <mailto:tcpprague-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpprague/>
List-Post: <mailto:tcpprague@ietf.org>
List-Help: <mailto:tcpprague-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpprague>, <mailto:tcpprague-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 31 Oct 2020 09:54:33 -0000


The co-authors of ECN L4S ID have been reviewing the correctness of the 
normative 'Prague' requirements.
This is the second of 2 emails, about 2 of the requirements that we 
think ought to be reworded a little.

If you agree with the rationale, but think the new wording still doesn't 
fully capture the requirement, pls suggest sthg better.
If you disagree with the rationale, pls discuss.

4.3.  Prerequisite Congestion Response

    o  A scalable congestion control MUST 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  <https://tools.ietf.org/html/rfc5681>] (seeAppendix A.1.4  <https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-10#appendix-A.1.4>  for

       Note that a scalable congestion control is not expected to change
       to setting ECT(0) while it falls back to coexist with Reno.

    o  A scalable congestion control MUST implement monitoring in order
       to detect a likely non-L4S but ECN-capable AQM at the bottleneck.
       On detection of a likely ECN-capable bottleneck it SHOULD be
       capable (dependent on configuration) of automatically adapting its
       congestion response to coexist with TCP Reno congestion controls
       [RFC5681] (see Appendix A.1.4 for rationale and a referenced

       Note that a scalable congestion control is not expected to change
       to setting ECT(0) while it falls back to coexist with Reno.

1/ The requirement as currently written says what an omniscient sender 
MUST do. So there's an implied requirement that a sender MUST be 
omniscient, which is of course impossible.
2/ The requirement needs to be recast to require a sender to aim to be 
as knowledgeable as possible. Then, what it does as a result needs to 
take into account the a priori likelihood of there being a non-L4S 
bottleneck present.
3/ This includes the possibility that the operator of the host knows 
that the network it serves has not deployed any single queue classic ECN 
AQM (e.g. in a CDN case they're doing out of band testing, or they've 
asked the ISP). So we've included the possibility of fall-back being 
disabled by configuration.
4/ Nonetheless, as has been pointed out on the list, there is still a 
possibility that there is a Classic ECN AQM somewhere else on the path 
(to continue the CDN example, perhaps beyond the ISP in a home network). 
The 'MUST monitor' requirement still stands to ensure the operator 
doesn't miss these cases.
5/ Then, if the server operators have disabled fall-back for their 
deployment, they can reconsider their policy or at least do more focused 
testing if they are frequently detecting a single-queue Classic ECN AQM.

Items 3-5 are the "react via management" model that I've talked about on 
the list, given the unfairness doesn't amount to starvation, and it is 
possible that the prevalence of the problem is very low.

Finally, after the bullet list of requirements in section 4.3, (which 
are prerequisites for setting the ECT1 codepoint), we propose to add the 
following requirement, as suggested on the tsvwg list:

       To participate in the L4S experiment, a scalable congestion 
control MUST
       be capable of being replaced by a Classic congestion control (by
       application and by administrative control). A Classic congestion 
       will not tag its packets with the ECT(1) codepoint.



Bob Briscoehttp://bobbriscoe.net/