IETF Logo Mail Archive

Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

Greg White <g.white@CableLabs.com> Wed, 20 March 2019 20:55 UTC

Return-Path: <g.white@CableLabs.com>
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 0E09113120D for <tsvwg@ietfa.amsl.com>; Wed, 20 Mar 2019 13:55:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cablelabs.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 dGGhbLTLZJG9 for <tsvwg@ietfa.amsl.com>; Wed, 20 Mar 2019 13:55:24 -0700 (PDT)
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-eopbgr750117.outbound.protection.outlook.com [40.107.75.117]) (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 C7748131202 for <tsvwg@ietf.org>; Wed, 20 Mar 2019 13:55:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cablelabs.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qpwCxbaGzlCRg/542L2Tph1syoW4T7g3umjJTV2aJMM=; b=d66cUbz6ELc4wcKOHdZNeknOHOq+O42Nvo3kHR5ChXPV8iTitCYurMqwi8OQPh9w1BPYAK0VUpBboJ0t7tCRkNoXDGdahowH4g+P/6Sw2sLyvBHjg7HaXa7N7k2CoHKWG+Q6AK85eijxAibQbwqNluJX2LkxNf4U8l4X3eywyMQ=
Received: from SN6PR06MB4655.namprd06.prod.outlook.com (52.135.117.85) by SN6PR06MB3856.namprd06.prod.outlook.com (52.132.125.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.14; Wed, 20 Mar 2019 20:55:20 +0000
Received: from SN6PR06MB4655.namprd06.prod.outlook.com ([fe80::75ce:14bc:e5e2:573c]) by SN6PR06MB4655.namprd06.prod.outlook.com ([fe80::75ce:14bc:e5e2:573c%5]) with mapi id 15.20.1709.015; Wed, 20 Mar 2019 20:55:20 +0000
From: Greg White <g.white@CableLabs.com>
To: Jonathan Morton <chromatix99@gmail.com>, "gorry@erg.abdn.ac.uk" <gorry@erg.abdn.ac.uk>
CC: Vint Cerf <vint@google.com>, tsvwg IETF list <tsvwg@ietf.org>, "David P. Reed" <dpreed@deepplum.com>, bloat <bloat@lists.bufferbloat.net>
Thread-Topic: [Bloat] [tsvwg] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104
Thread-Index: AQHU31hHc+/JE50LYkeVF+S247T0iKYUmy0A
Date: Wed, 20 Mar 2019 20:55:20 +0000
Message-ID: <FDA48F4C-415B-4B8E-9CC7-2AAAD4DC3BE8@cablelabs.com>
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> <5C9296E1.4010703@erg.abdn.ac.uk> <F62C4839-0489-475F-AD8F-58913EEEEC0F@gmail.com>
In-Reply-To: <F62C4839-0489-475F-AD8F-58913EEEEC0F@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.14.0.181208
authentication-results: spf=none (sender IP is ) smtp.mailfrom=g.white@CableLabs.com;
x-originating-ip: [2620:0:2b10:23:ad72:d851:e23:40ab]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: dd687ba2-a3f5-45ae-4501-08d6ad765d79
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600127)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:SN6PR06MB3856;
x-ms-traffictypediagnostic: SN6PR06MB3856:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <SN6PR06MB38561DB2199A4D2D20D3C5B3EE410@SN6PR06MB3856.namprd06.prod.outlook.com>
x-forefront-prvs: 098291215C
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(39850400004)(136003)(366004)(346002)(396003)(189003)(199004)(76176011)(25786009)(476003)(68736007)(81166006)(86362001)(186003)(6436002)(99286004)(71190400001)(8936002)(71200400001)(83716004)(14454004)(33656002)(2616005)(6486002)(102836004)(6506007)(2906002)(46003)(5660300002)(11346002)(53546011)(478600001)(36756003)(446003)(6246003)(106356001)(97736004)(305945005)(6116002)(6306002)(6512007)(105586002)(54906003)(4326008)(486006)(82746002)(110136005)(316002)(8676002)(81156014)(256004)(966005)(2501003)(53936002)(93886005)(7736002)(58126008)(229853002)(85282002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR06MB3856; H:SN6PR06MB4655.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: CableLabs.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: TP1rfL7hDPKKaD+/73cjZy/FaMlKdcXQxHqxjztduN8fZTiKkGIMKsfbtCv5q43uO0lboaMI6s5LPXW4XiWQETbMKCSeEW6ue78rtip+FqUbYcndJaDMP0cDl7hjvun2sIjS21m1qiyi1JbSmMkCAmWvviGROnGNtGS6tCO1gdxhD88On9ZcSMuORVBPfj9K5LVOI+lY/wnx96evQ98PilpnkQ62nOyIHR45b2XKYgi1HN4jqDEqrNQ4xXoMh7Ei4Wbk5O5EZ+bl4Eaa0RrkfFNXA4WDefehjlbQ7rdOYJySQJoYPTGMsHlAVkxeh4uLbFIiOOq2s0YC3AyjI/090Cv56msc1s5ONpE8OHjCkeVwOSWoHWrIvFoysgCsTUDw90PMxFCbamlJzJl+KlfLTbN6hXj1u4gaJUGRDdTZQ20=
Content-Type: text/plain; charset="utf-8"
Content-ID: <89A2A760C0922646BA1897E5B70ED862@namprd06.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: cablelabs.com
X-MS-Exchange-CrossTenant-Network-Message-Id: dd687ba2-a3f5-45ae-4501-08d6ad765d79
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Mar 2019 20:55:20.4127 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: ce4fbcd1-1d81-4af0-ad0b-2998c441e160
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR06MB3856
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/Eqzg1aQ2JzPUg5HH_T_jdtQObvI>
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: Wed, 20 Mar 2019 20:55:26 -0000

In normal conditions, L4S offers "Maximize Throughput" +  "Minimize Loss" + "Minimize Latency" all at once.  It doesn't require an application to have to make that false choice (hence the name "Low Latency Low Loss Scalable throughput").  

If an application would prefer to "Minimize Cost", then I suppose it could adjust its congestion control to be less aggressive (assuming it is congestion controlled). Also, as you point out the LEPHB could be an option as well.

What section 4.1 in the dualq draft is referring to is a case where the system needs to protect against unresponsive, overloading flows in the low latency queue.   In that case something has to give (you can't ensure low latency & low loss to e.g. a 100 Mbps unresponsive flow arriving at a 50 Mbps bottleneck).

-Greg




On 3/20/19, 2:05 PM, "Bloat on behalf of Jonathan Morton" <bloat-bounces@lists.bufferbloat.net on behalf of chromatix99@gmail.com> wrote:

    > On 20 Mar, 2019, at 9:39 pm, Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:
    > 
    > Concerning "Maximize Throughput", if you don't need scalability to very high rates, then is your requirement met by TCP-like semantics, as in TCP with SACK/loss or even better TCP with ABE/ECT(0)?
    
    My intention with "Maximise Throughput" is to support the bulk-transfer applications that TCP is commonly used for today.  In Diffserv terminology, you may consider it equivalent to "Best Effort".
    
    As far as I can see, L4S offers "Maximise Throughput" and "Minimise Latency" services, but not the other two.
    
     - Jonathan Morton
    
    _______________________________________________
    Bloat mailing list
    Bloat@lists.bufferbloat.net
    https://lists.bufferbloat.net/listinfo/bloat

v2.23.0 | Report a Bug | By Email