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

Dave Taht <dave.taht@gmail.com> Tue, 06 August 2019 15:36 UTC

Return-Path: <dave.taht@gmail.com>
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 8F1161200B8; Tue, 6 Aug 2019 08:36:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 PyWovfKecPKG; Tue, 6 Aug 2019 08:36:09 -0700 (PDT)
Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DD7412003E; Tue, 6 Aug 2019 08:36:09 -0700 (PDT)
Received: by mail-oi1-x235.google.com with SMTP id a127so67140452oii.2; Tue, 06 Aug 2019 08:36:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=HZxIUso5tTWxDEm1otnDpiERUu/1tjvmsPyHllCK21E=; b=b8Y+cK6oBr2jcosO6jhELRSrOmjklYQsi66/+RvohaQvPghRxVy1BIOQGQNy8C0Iu1 IXTIGrRVQ0vo3E3x2Wrn0ug4K5j9qT4fcY3m07N/6jv9xmPUG+BD8FwjZnt3hz1XBZCo tx2taTiSkC3GiLTpO4dAkPLtsaZlywagYaRAie8sIUTLNqw94Fah9T0Tr8NxqA/Ol82w KoHFbmcLjjayhr5FoEGSpuMid4AqdNhoUXv9iVS56Buw48peV3VRQsXLOYh2irsoBSel hqPKXMYT96mX52rfilibUju84R90DYv2O/q1sI/KzxrPicYS5aJw6McPtWQ2ExZxW2vu sP9w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=HZxIUso5tTWxDEm1otnDpiERUu/1tjvmsPyHllCK21E=; b=fSvHP7Qte8rnnDEjuSbLfWMCnU0UCsnBF+mhPz5nzSu/+hh68Hm471yQFYX3dj+7ad uQE87ZKUVzfRQbCMdd4qOPcjPUdlJcq7kAM6NIZ/QBAmjtIBJV2i+3GB049jwVuX/YaB +8sO9hL/s7e3KYea8r4jW1FIuA87bPI4JdVeIl6RAFx+wD+vEaqdWHPFQh7PFg09OwyQ diwLdTWkCliOae8SbS1pMtMaXIGuxpQ9li0hogbQc6yE9Q+K3Wwhr3nvkW/TnPmxDlzu JsOMIS5nphdyM8v8ydaETVgvGus9hDhGsrgTX/a4pXl5YOQPLj8CE87OZoBk5RmzzuJL qKUQ==
X-Gm-Message-State: APjAAAU5I8ZG0lldFHnzs2vMBHpmRwWAa24XgcdMT02K5FFjlEOfaMte pmcfqzXuIkgMw932T0T9VSuoIdIbBDb90I0C+uY=
X-Google-Smtp-Source: APXvYqxHAVznyy9i3poEkx4BHaT8kTU6lYMOXF2lAmQtV+Vhu8WGoyrCSjtBCElDXDswZM8j1ME3use+g+hPYC+kQ2I=
X-Received: by 2002:a02:3093:: with SMTP id q141mr4835966jaq.128.1565105768541; Tue, 06 Aug 2019 08:36:08 -0700 (PDT)
MIME-Version: 1.0
References: <24f7b15a-129f-ca44-60e0-32c7d23eadf4@bobbriscoe.net> <E54BA49C-0790-48B4-82BB-4C0F3FE3FB20@gmail.com> <FRXPR01MB0710085AE4AEFA896819AFA69CD90@FRXPR01MB0710.DEUPRD01.PROD.OUTLOOK.DE> <0E44351D-2520-45AD-A10A-8E2FFE186722@gmx.de> <LEXPR01MB0463C090812BEA6DAB566A1E9CDA0@LEXPR01MB0463.DEUPRD01.PROD.OUTLOOK.DE> <20C58AE1-CAC4-480F-8E80-1F5A09ED53EA@gmx.de> <LEXPR01MB046367DE6489CE0F20E4B2359CDA0@LEXPR01MB0463.DEUPRD01.PROD.OUTLOOK.DE> <3AB4DBF2-C0B3-45EE-8E82-E2D337EA346E@gmx.de> <alpine.DEB.2.20.1908061122560.7741@uplift.swm.pp.se> <LEXPR01MB04633F2E6945D6AAE9D4F18B9CD50@LEXPR01MB0463.DEUPRD01.PROD.OUTLOOK.DE> <ED78E4C4-D86F-4068-99C4-7F98D88FB481@gmail.com>
In-Reply-To: <ED78E4C4-D86F-4068-99C4-7F98D88FB481@gmail.com>
From: Dave Taht <dave.taht@gmail.com>
Date: Tue, 06 Aug 2019 08:35:56 -0700
Message-ID: <CAA93jw5yFj9AOyH25ZGAo=SfPxw9O1gmKomW+6VNrB60nQE8gQ@mail.gmail.com>
To: Jonathan Morton <chromatix99@gmail.com>
Cc: Ruediger.Geib@telekom.de, tcpm IETF list <tcpm@ietf.org>, ECN-Sane <ecn-sane@lists.bufferbloat.net>, tsvwg IETF list <tsvwg@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/0rl0EH9Emg2yTwhd6tvCrJvOeY0>
Subject: Re: [tcpm] [Ecn-sane] [tsvwg] 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: Tue, 06 Aug 2019 15:36:12 -0000

On Tue, Aug 6, 2019 at 8:28 AM Jonathan Morton <chromatix99@gmail.com> wrote:
>
> > On 6 Aug, 2019, at 5:34 pm, <Ruediger.Geib@telekom.de> <Ruediger.Geib@telekom.de> wrote:
> >
> > Public peerings and not well dimensioned networks may suffer from regular congestion. I'm not sure to which extent technical standards can significantly improve service quality in that situation. IP transport must work as good as possible also in such a situation, of course.
>
> Obviously the application of AQM will not magically improve total throughput.  What it can do, however, is reduce latency and packet loss, and thereby improve perceived reliability of the service.  It may even improve goodput for the same throughput - an increase in efficiency.
>
> This is especially true under emergency overload conditions, which is when people most desperately want a functioning network, but it is most likely to collapse under the strain.  Often a disaster will incidentally knock out some proportion of network infrastructure in the area, turning a previously well-proportioned network into an under-proportioned one, simultaneously with a sharp increase in demand as people try to find out what is going on or communicate with friends and relatives, and emergency response teams also try to coordinate their essential work.

Overbuffering, the silent killer:
http://blog.cerowrt.org/post/bufferbloat_on_the_backbone/

> So IMO networks should be designed to work well when congested, even when they are also designed to never *be* congested.  Technical specifications already exist and are well tested for this purpose.  Having them built in and turned on from the factory would be a great step forward.

I live in california, where I kind of expect the network to collapse
in the next Big One.

>
>  - Jonathan Morton
> _______________________________________________
> Ecn-sane mailing list
> Ecn-sane@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/ecn-sane



-- 

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740