Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104
Bob Briscoe <ietf@bobbriscoe.net> Thu, 21 March 2019 13:24 UTC
Return-Path: <ietf@bobbriscoe.net>
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 EB38B12865E for <tsvwg@ietfa.amsl.com>; Thu, 21 Mar 2019 06:24:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=bobbriscoe.net
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 jQsCeiihNQkT for <tsvwg@ietfa.amsl.com>; Thu, 21 Mar 2019 06:24:12 -0700 (PDT)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 A448E12423B for <tsvwg@ietf.org>; Thu, 21 Mar 2019 06:24:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=44Ea64MuBeIkpIS9GopopQ/q1xdgE8fDOQdTZHim2Ks=; b=mJ9N6maQc4rvuH4Jf4Pt5Vlg9F +ylKMbTHbGRr8N/4TggBTg5FKTKg/OKhZjQ8c2lmF551SSD+j6Nho2kQ8YXLB0WL6pk6yUtsYfMWa poShItZHFRzSLab5l0QDw1K0sYRCRTPNOeFO8vztVZbTqbKy5yB/iya/sYr4f/aqjpG01UBBwUR6b hyWKLw6NybjDzG96/N9qRGPJDKnHJrQ217soS6aanZ+gbNdRHP3HeDaJ4q5dTNG0a5xpLQPTLLbTP f4uGwKzkIYY/RQs+nrVs1JwN+wcZCq7X4GLEjBa45K7+b5ly3EthpEAHLU8fPbWX2TOK01mIg6M7t F/zKvhhg==;
Received: from [195.39.71.253] (port=58160 helo=[172.31.96.105]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from <ietf@bobbriscoe.net>) id 1h6xg2-0002iY-RB; Thu, 21 Mar 2019 13:24:11 +0000
To: "Bless, Roland (TM)" <roland.bless@kit.edu>, Jonathan Morton <chromatix99@gmail.com>
Cc: tsvwg IETF list <tsvwg@ietf.org>, bloat <bloat@lists.bufferbloat.net>
References: <d91a6a71-5898-9571-2a02-0d9d83839615@bobbriscoe.net> <CAA93jw5MTdn9EQgpZ0xrjqEi7UKqH3H_741anoB+pa0dtD=fpA@mail.gmail.com> <1E80578D-A589-4CA0-9015-B03B63042355@gmx.de> <CAA93jw7jvjbZkEgO8xc03uCayo+o-uENxxAkzQOaz_EZSLhocw@mail.gmail.com> <27FA673A-2C4C-4652-943F-33FAA1CF1E83@gmx.de> <1552669283.555112988@apps.rackspace.com> <alpine.DEB.2.20.1903151915320.3161@uplift.swm.pp.se> <7029DA80-8B83-4775-8261-A4ADD2CF34C7@akamai.com> <CAHxHggfPCqf9biCDmHMqA38=4y6gY6pFtRVMjMrrzYfLyRBf-g@mail.gmail.com> <1552846034.909628287@apps.rackspace.com> <5458c216-07b9-5b06-a381-326de49b53e0@bobbriscoe.net> <AC14ACBB-A7CC-40E0-882C-2519D05ADC05@akamai.com> <7e49b551-22e5-5d54-2a1c-69f53983d7e5@bobbriscoe.net> <04E62EA7-82EF-4F1B-A86D-5A23CA3B190A@gmail.com> <f331e710-ed2c-8628-4c82-f162d9cc8763@bobbriscoe.net> <C4BED95B-A169-473E-B857-C26BC2AFBE54@gmail.com> <10ac0f0f-1635-a0b3-6150-2ff3d63be788@bobbriscoe.net> <3d6b1619-ce5d-5649-0436-72bb10115e45@kit.edu>
From: Bob Briscoe <ietf@bobbriscoe.net>
Message-ID: <b0320cc2-28ec-63e8-c2b8-594616b63cfe@bobbriscoe.net>
Date: Thu, 21 Mar 2019 14:24:04 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1
MIME-Version: 1.0
In-Reply-To: <3d6b1619-ce5d-5649-0436-72bb10115e45@kit.edu>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
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: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/2xOsIzInL0ZALhra3BvJB7dH38s>
Subject: Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104
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: Thu, 21 Mar 2019 13:24:15 -0000
Roland, On 21/03/2019 08:49, Bless, Roland (TM) wrote: > Hi, > > Am 21.03.19 um 09:02 schrieb Bob Briscoe: >> Just to rapidly reply, >> >> >> On 21/03/2019 07:46, Jonathan Morton wrote: >>> The ECN field was never intended to be used as a classifier, except to >>> distinguish Not-ECT flows from ECT flows (which a middlebox does need >>> to know, to choose between mark and drop behaviours). It was intended >>> to be used to convey congestion information from the network to the >>> receiver. SCE adheres to that ideal. >> Each PHB has a forwarding behaviour a DSCP re-marking behaviour and an >> ECN marking behaviour. The ECN field is the claissifer for the ECN >> marking behaviour. > That's exactly the reason, why using ECT(1) as classifier for L4S > behavior is not the right choice. L4S should use a DSCP for > classification, because it is actually defining a PHB. 1/ First Terminology The definition of 'PHB' includes the drop or ECN-marking behaviour. For instance, you see this in WRED or in PCN (Pre-Congestion Notification). If you want to solely talk about scheduling, pls say the scheduling PHB. 2/ The architectural intent of the ECN field For many years (long before we thought of L4S) I have been making sure that ECN propagation through the layers supports the duality of ECN behaviours as both a classifier (on the way down from L7/L4 to L3/2) and as a return value (on the way back up). The architecture of ECN is determined by the valid codepoint transitions. They are: 1. 00->11 2. 10->11 3. 01->11 4. 10->01 The first three were in RFC3168, but it did not preclude the fourth. The fourth was first standardized in RFC6660 (which I co-authored). This had to be isolated from the e2e use of ECN by inclusion of a DSCP as well. The relatively late addition of the fourth approach means that an attempt to mark using the SCE approach (10->01) is more likely to find that it gets reversed when the outer header is decapsulated, if the decapsulator hasn't been updated to the latest RFC that catered for this fourth transition (RFC6040, also co-authored by me). L4S follows the original RFC3168 approach SCE uses the fourth So, SCE proposes to use /a/ correct approach, but it might not work. Whereas L4S uses the original correct approach. 3a/ DualQ L4S AQMs With the DualQ, the difference between the two queues is both in their ECN marking behaviour and in their forwarding/scheduling behaviour. However, whenever there's traffic in the classic queue the coupling between the AQMs overrides the network scheduler. The coupling is solely ECN behaviour not scheduling behaviour. So the primary difference between the queues is in their ECN-marking behaviour. What do I mean by "the coupling overrides the network scheduler"? The network scheduler certainly does give priority to L4S packets whenever they arrive, but the coupling makes the L4S sources control how often packets arrive. It's tough to reason about, because we haven't had a mechanism like this before. 2b/ FQ L4S AQMs If the AQM is implemented with per flow queues, the picture is clearer. The only difference between the queues is in the ECN marking behaviour of the different AQMs. Bob > Regards > Roland -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/
- Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpP… Bob Briscoe
- Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpP… Dave Taht
- Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpP… Jonathan Morton
- Re: [tsvwg] Implementation and experimentation of… Greg White
- Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpP… Dave Taht
- Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpP… Ingemar Johansson S
- Re: [tsvwg] [Ecn-sane] [Bloat] [iccrg] Fwd: [tcpP… Sebastian Moeller
- Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpP… Holland, Jake
- Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpP… Gorry Fairhurst
- Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpP… Stephen Hemminger
- Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpP… Holland, Jake
- Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpP… Jonathan Morton
- Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpP… Jonathan Morton
- Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpP… Holland, Jake
- Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpP… Greg White
- Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpP… Greg White
- Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpP… Jonathan Morton
- Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpP… Holland, Jake
- Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpP… Greg White
- Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpP… Bob Briscoe
- Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpP… Jonathan Morton
- Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpP… Holland, Jake
- Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpP… Bob Briscoe
- Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpP… Jonathan Morton
- Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpP… Bob Briscoe
- Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpP… Sebastian Moeller
- Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpP… Bless, Roland (TM)
- Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpP… Bob Briscoe
- Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpP… Bless, Roland (TM)
- Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpP… Bob Briscoe
- Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpP… Bob Briscoe
- Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpP… alex.burr@ealdwulf.org.uk