Re: [tcpm] [Ecn-sane] [tsvwg] ECN CE that was ECT(0) incorrectly classified as L4S

Dave Taht <> Fri, 02 August 2019 11:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 560DD120096; Fri, 2 Aug 2019 04:10:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mUozj34FynlC; Fri, 2 Aug 2019 04:10:25 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 052D912004A; Fri, 2 Aug 2019 04:10:25 -0700 (PDT)
Received: by with SMTP id e20so18332795iob.9; Fri, 02 Aug 2019 04:10:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=pVJGExsKLlIOof1pxpFUuxa1/KESzXQPi99nbi+PJoo=; b=hf1kwvGn4qv1rBZrN1oFMNPLKeVZ/v1Yu7YV1IsuVP0nzZuDVxU8HC/xlTojv++tbC YV8FgiGK4Vib7Wwe9tAWf5W4xoekOSeH02hdEIccs3tMTbWnF8Gg3rB/Ep2Uz+NrjHHm KXDo5pKH2TlAhTmEkonQoLJj5luniWTEr4Tb9EGiVBEUFiLb6gsi3o6jPx/DxkhOO+T5 OzgF2iN2sKIc/ccs883xaL43ySLg9ot2Fsz84InNNgG6Tc6NFhkPYW/C57IBBjTOgvzY lid5rp1TQ8qIQt/cIJg35HLSwG+Fd0IuIi3ufKgL0Z8OzzgngOTihNHDVfQRZ7PnEQdu 514w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=pVJGExsKLlIOof1pxpFUuxa1/KESzXQPi99nbi+PJoo=; b=DXBnxkaFsPG2EiookrY1hZT4tvFLWSMVvpfR6yd/KcBzX+ACkT1GQ0EgubtlwvXFQ3 PeSLoGN68UwjN5sd/tjS5IZCSCgiF8557vXYKP+0Kt4ueWFKJbbWZIaeZ6OS1yioSBIH YTT0RBRA2MD00Pn9+vM33s/NWeKEkvPOcpzGXMUJZwKqwYur9U4e+DEUuJX15rIGHe07 cZ5KCszNvVtcml8hp6W9B4SiiDoynsH94n1qm5ROrdTujqdc0sTBl23T54QEg33LOciU u5hb3CNkPX7SWtW0LVrU8SP9CRQ5+lHQ4txqteDBf9gYJX8UfwFPC5OAs+WW5KjauZn+ PdDw==
X-Gm-Message-State: APjAAAU+Ie+mpSwCed/WaTd1qxN/vuipXCFLcdoxAp9EEgb6/xfryKch UxdRNnPu7qoN0xHvHO187sYULQkczZ1AF1penUQ=
X-Google-Smtp-Source: APXvYqwC8Unfs0cpHNUpmeYz3BbReJq3nJ7hrDl8xFxROTHOCDoOYaMJmbwhCSWr1AqvvWuduZOfk1PEpzfDiXM/nNQ=
X-Received: by 2002:a5d:9d42:: with SMTP id k2mr11577004iok.45.1564744224165; Fri, 02 Aug 2019 04:10:24 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <FRXPR01MB0710085AE4AEFA896819AFA69CD90@FRXPR01MB0710.DEUPRD01.PROD.OUTLOOK.DE> <>
In-Reply-To: <>
From: Dave Taht <>
Date: Fri, 02 Aug 2019 04:10:11 -0700
Message-ID: <>
To: Jonathan Morton <>
Cc:, tcpm IETF list <>, ECN-Sane <>, tsvwg IETF list <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [tcpm] [Ecn-sane] [tsvwg] ECN CE that was ECT(0) incorrectly classified as L4S
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 02 Aug 2019 11:10:27 -0000

On Fri, Aug 2, 2019 at 2:47 AM Jonathan Morton <> wrote:
> > On 2 Aug, 2019, at 9:29 am, <> <> wrote:
> >
> > Hi Jonathan,
> >
> > could you provide a real world example of links which are consecutively narrower than sender access links?
> >
> > I could figure out a small campus network which has a bottleneck at the Internet access and a second one connecting the terminal equipment. But in a small campus network, the individual terminal could very well have a higher LAN access bandwidth, than the campus - Internet connection (and then there's only one bottleneck again).
> >
> > There may be a tradeoff between simplicity and general applicability. Awareness of that tradeoff is important. To me, simplicity is the design aim.
> A progressive narrowing of effective link capacity is very common in consumer Internet access.  Theoretically you can set up a chain of almost unlimited length of consecutively narrowing bottlenecks, such that a line-rate burst injected at the wide end will experience queuing at every intermediate node.  In practice you can expect typically three or more potentially narrowing points:

0: Container and vm users are frequently using htb + something to keep
their bandwidths under control.

0.5: Cloudy providers use "something" to also rate limit traffic.
Policers and shapers, I assume.

> 1: Core to Access network peering.  Most responsible ISPs regularly upgrade these links to minimise congestion, subject to cost effectiveness.  Some consumer ISPs however are less responsible, and permit regular congestion here, often on a daily and/or weekly cycle according to demand.  Even the responsible ones may experience short-term congestion here due to exceptional events.  Even if the originating server's NIC is slower than the peering link, queuing may occur here if the link is congested overall due to statistical multiplexing.
> 2: Access to Backhaul provisioning shaper.  Many ISPs have a provisioning shaper to handle "poverty tariffs" with deliberately limited capacity.  It may also be used to impose a sanity check on inbound traffic bursts, to limit backhaul network traffic to that actually deliverable to the customer (especially when the backhaul network is itself subcontracted on a gigabytes-carried basis, as is common in the UK).  In the ADSL context it's often called a BRAS.
> 3: Backhaul to head-end device.  Generally the backhaul network is sized to support many head-end devices, each of which serves some number of consumer last-mile links.  I'm being deliberately generic here; it could be a CMTS on a cable network, a DSLAM in a phone exchange, a cell tower, or a long-range wifi hub.  In many cases the head-end device shares several subscribers' lines over a common last-mile medium, so there is still some statistical multiplexing.  In the particular case of a cell tower, the subscriber usually gets less link capacity (due to propagation conditions) than his tariff limit.
> 4: CPE bufferbloat mitigation shaper.  This is *post-last-mile* ingress shaping, with AQM and FQ, to reduce the effects of the still-ubiquitous dumb FIFOs on the above bottlenecks, especially the head-end device.  The IQrouter is a ready-made CPE device which does this.
> 5: LAN, wifi, or powerline link.  Most people now have GigE, but 100base-TX is still in use in cheaper CPE and some low-end computers, and this will be a further bottleneck in cases where the last mile is faster.  For example, the Raspberry Pi has only just upgraded to GigE in its latest versions, and used 100base-TX before.  Wifi is also a likely bottleneck, especially if the mobile station is on the opposite side of the house from the base CPE, and is additionally a "bursty MAC" with heavy aggregation.  Some CPE now runs airtime-fairness and FQ-AQM on wifi to help manage that.
> I think the above collection is not at all exotic.  Not all of these will apply in every case, or at all times in any given case, but it is certainly possible for all five to apply consecutively.
>  - Jonathan Morton
> _______________________________________________
> Ecn-sane mailing list


Dave Täht
CTO, TekLibre, LLC
Tel: 1-831-205-9740