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

<Ruediger.Geib@telekom.de> Fri, 02 August 2019 08:29 UTC

Return-Path: <Ruediger.Geib@telekom.de>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13D9E120025; Fri, 2 Aug 2019 01:29:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level:
X-Spam-Status: No, score=-4.299 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_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de
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 4RZ0ZfGeqaW2; Fri, 2 Aug 2019 01:29:37 -0700 (PDT)
Received: from mailout21.telekom.de (mailout21.telekom.de [194.25.225.215]) (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 AC51412000F; Fri, 2 Aug 2019 01:29:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1564734575; x=1596270575; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=kbCBAiZTa1DBX0O6bOQWzhWBSI1kRuuUT/+iio1pwoU=; b=YYH2wPbNv+3PVOsEy6wemAllVyRFVfbfmPiOKNfvAd7VtnBLvz9zeoEb 3hBlstYPhzHwQcdGWeoD7BSmoC/hljl1oNDCZCo7EOfms5/99JEJyGguw qYBKcb3u4n/BbyjizeUGQsTzPRB3ZMXrmOL0A9SAYzXwd0J/hL98JlzPp s2c9NLka/pKA857u2VpiBxzzrejVq/TBbQIPfXQudPzq6oj85y3R1oTab ecS7DhCvYLwmUPPjZ7pRT7Roe1oDwcGxgy3sVJlK140E0dkqY2jpvClVv NGFGk1EO2PulsOXlwUNqb5dF+AQHT/eji0ChEevC/GG+GexKaZeIady52 A==;
Received: from qdec94.de.t-internal.com ([10.171.255.41]) by MAILOUT21.dmznet.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Aug 2019 10:29:32 +0200
X-IronPort-AV: E=Sophos;i="5.64,337,1559512800"; d="scan'208";a="471894858"
X-MGA-submission: MDHNxomqfot6fntjWtUYuFbIHqZZw+qxQCtgWxE+Q47jHoZs9FStjmx6JDnW70s8TKdQIaQ7DClZo5dLDHTOvsaWzSyJNk7sENOniNmXxlokb9CfPsuS5h2yriHnUULGmPvKVvy/gbTd7iH0ME8WEKib9ZuWo+ZoCggLwGzOwNqvVQ==
Received: from he105709.emea1.cds.t-internal.com ([10.169.118.41]) by QDEC97.de.t-internal.com with ESMTP/TLS/AES256-SHA; 02 Aug 2019 10:29:33 +0200
Received: from HE105715.EMEA1.cds.t-internal.com (10.169.118.51) by HE105709.emea1.cds.t-internal.com (10.169.118.41) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 2 Aug 2019 10:29:33 +0200
Received: from HE104164.emea1.cds.t-internal.com (10.171.40.35) by HE105715.EMEA1.cds.t-internal.com (10.169.118.51) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 2 Aug 2019 10:29:33 +0200
Received: from GER01-FRA-obe.outbound.protection.outlook.de (51.4.80.15) by O365mail06.telekom.de (172.30.0.233) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 2 Aug 2019 10:29:30 +0200
Received: from FRXPR01MB0710.DEUPRD01.PROD.OUTLOOK.DE (10.158.154.26) by FRXPR01MB0582.DEUPRD01.PROD.OUTLOOK.DE (10.158.153.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2136.17; Fri, 2 Aug 2019 08:29:32 +0000
Received: from FRXPR01MB0710.DEUPRD01.PROD.OUTLOOK.DE ([fe80::64eb:180c:69d1:8be1]) by FRXPR01MB0710.DEUPRD01.PROD.OUTLOOK.DE ([fe80::64eb:180c:69d1:8be1%5]) with mapi id 15.20.2115.005; Fri, 2 Aug 2019 08:29:32 +0000
From: Ruediger.Geib@telekom.de
To: chromatix99@gmail.com
CC: tcpm@ietf.org, ecn-sane@lists.bufferbloat.net, tsvwg@ietf.org
Thread-Topic: [tsvwg] [Ecn-sane] ECN CE that was ECT(0) incorrectly classified as L4S
Thread-Index: AQHVNmzjJ0yZ6qt6w0KBBMUQQa2wF6bnpeTw
Date: Fri, 02 Aug 2019 08:29:32 +0000
Message-ID: <FRXPR01MB0710085AE4AEFA896819AFA69CD90@FRXPR01MB0710.DEUPRD01.PROD.OUTLOOK.DE>
References: <24f7b15a-129f-ca44-60e0-32c7d23eadf4@bobbriscoe.net> <E54BA49C-0790-48B4-82BB-4C0F3FE3FB20@gmail.com>
In-Reply-To: <E54BA49C-0790-48B4-82BB-4C0F3FE3FB20@gmail.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Ruediger.Geib@telekom.de;
x-originating-ip: [164.19.3.96]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: ec9e52cc-9016-4cb2-e613-08d717238b5c
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:FRXPR01MB0582;
x-ms-traffictypediagnostic: FRXPR01MB0582:
x-microsoft-antispam-prvs: <FRXPR01MB0582E8C6A20625D50B4DD6B69CD90@FRXPR01MB0582.DEUPRD01.PROD.OUTLOOK.DE>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 011787B9DD
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39860400002)(396003)(136003)(346002)(366004)(199004)(189003)(71200400001)(71190400001)(446003)(6916009)(9686003)(3846002)(6116002)(76176011)(52396003)(256004)(55016002)(186003)(7696005)(4326008)(33656002)(8676002)(53546011)(102836004)(53936002)(316002)(26005)(66066001)(7736002)(66574012)(1411001)(2906002)(305945005)(66946007)(76116006)(476003)(81166006)(66556008)(64756008)(66446008)(81156014)(14454004)(66476007)(14444005)(11346002)(5660300002)(45776006)(86362001)(8936002)(54906003)(68736007)(486006)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:FRXPR01MB0582; H:FRXPR01MB0710.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 87gu36q1vu6kzb0u/dvjVqkmsZDP3kZzWix3Ea512ZF5f57ceQZmiSd/IGc2931mzdOjfYXYFldsYtwpnUG2ceqZwicxy5d07KQAkCfhTqfYvJ1ujY59neYBan6W+9SwH+PMkkH57NB74ZiO4IvQ7kQsB8zrX/Xi4TbL/7ekHzDK4trLJEv8QtRgByAKTcRL7bAY/kOofrKhyBA1JDi2W1Dp17u0lq4SikKWqtOLRK/BTNHlHCKRC6YuuXtcxnsMBJ8M9oEwNdvLuqvMxnpnLUXOqqzxMO6ux5LOmqQOkymSRIO+PLrIc5qKqVNDnMs4C3zi9U4DSDPW7EcE8oXg9B4R6TI+aMxjc6/Pn5oSV9qrnWWFFq6g5MJnCbrVcTumXxFRVzzb5TBqSDSWLP2SM4cQWTz3WneAgAlTYe6T2AI=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: ec9e52cc-9016-4cb2-e613-08d717238b5c
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Aug 2019 08:29:32.4540 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Ruediger.Geib@telekom.de
X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRXPR01MB0582
X-OriginatorOrg: telekom.de
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/tCEG7ENVCJhhsWQ-RB49SoFrPKo>
Subject: Re: [tcpm] [tsvwg] [Ecn-sane] ECN CE that was ECT(0) incorrectly classified as L4S
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Aug 2019 08:29:39 -0000

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. 

Regards,

Ruediger 

-----Ursprüngliche Nachricht-----
Von: tsvwg <tsvwg-bounces@ietf.org> Im Auftrag von Jonathan Morton
Gesendet: Dienstag, 9. Juli 2019 17:41
An: Bob Briscoe <ietf@bobbriscoe.net>
Cc: tcpm IETF list <tcpm@ietf.org>; ecn-sane@lists.bufferbloat.net; tsvwg IETF list <tsvwg@ietf.org>
Betreff: Re: [tsvwg] [Ecn-sane] ECN CE that was ECT(0) incorrectly classified as L4S

> On 13 Jun, 2019, at 7:48 pm, Bob Briscoe <ietf@bobbriscoe.net> wrote:
> 
>       1.  It is quite unusual to experience queuing at more than one
>           bottleneck on the same path (the available capacities have to
>           be identical).

Following up on David Black's comments, I'd just like to note that the above is not the true criterion for multiple sequential queuing.

Many existing TCP senders are unpaced (aside from ack-clocking), including FreeBSD, resulting in potentially large line-rate bursts at the origin - especially during slow-start.  Even in congestion avoidance, each ack will trigger a closely spaced packet pair (or sometimes a triplet).  It is then easy to imagine, or to build a testbed containing, an arbitrarily long sequence of consecutively narrower links; upon entering each, the burst of packets will briefly collect in a queue and then be paced out at the new rate.

TCP pacing does largely eliminate these bursts when implemented correctly.  However, Linux' pacing and IW is specifically (and apparently deliberately) set up to issue a 10-packet line-rate burst on startup.  This effect has shown up in SCE tests to the point where we had to patch this behaviour out of the sending kernel to prevent an instant exit from slow-start.

 - Jonathan Morton