Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104
"Holland, Jake" <jholland@akamai.com> Thu, 21 March 2019 00:41 UTC
Return-Path: <jholland@akamai.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 7BCD01275F3 for <tsvwg@ietfa.amsl.com>; Wed, 20 Mar 2019 17:41:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.851
X-Spam-Level:
X-Spam-Status: No, score=-1.851 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, KHOP_DYNAMIC=0.85, RCVD_IN_DNSWL_LOW=-0.7, 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=akamai.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 h_2jcXxVlFjg for <tsvwg@ietfa.amsl.com>; Wed, 20 Mar 2019 17:41:11 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 BB88612DF71 for <tsvwg@ietf.org>; Wed, 20 Mar 2019 17:41:11 -0700 (PDT)
Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x2L0anCa002186; Thu, 21 Mar 2019 00:41:08 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=Rqc/etblzUHags/+CIry7Yy3lmW5OOomARUC7KXrsww=; b=N+mRUe+2TDMbetiuLAV1QLplzbagKMrgTtzYaf4TxUeWEzn9djDp+Jf3d0R62GmBpifn zX9DY8xhFYwtH0lAJQgqc64XgS/7MdI2dFWjT5RmynV7rNjA8a78qcii1IJ58qR0fIGL NtgGTVN4j/OyjZSODHhZ46KUdkJxZhMMy1sZmyuhisR8KkNmyMkP0bb4nbo0UNopBKEO ylegL5h/sOwvn9KG4XewUcnkc7lwezdEceD3mWZ1szgo75MdAkbvn0s5BH/K+H7h3OMr 12NyLXjG2qcqBoghtEl6vG4lS5kcU/i3ku7dju6xwadpFjGVcnhfeem7MG8+auk3e++A ng==
Received: from prod-mail-ppoint3 (a96-6-114-86.deploy.static.akamaitechnologies.com [96.6.114.86] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2rbw7bgfp1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 21 Mar 2019 00:41:08 +0000
Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x2L0WXMt031838; Wed, 20 Mar 2019 20:41:08 -0400
Received: from email.msg.corp.akamai.com ([172.27.27.25]) by prod-mail-ppoint3.akamai.com with ESMTP id 2r8vfytbt1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 20 Mar 2019 20:41:07 -0400
Received: from USTX2EX-DAG1MB4.msg.corp.akamai.com (172.27.27.104) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.27.104) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 20 Mar 2019 19:41:07 -0500
Received: from USTX2EX-DAG1MB4.msg.corp.akamai.com ([172.27.6.134]) by ustx2ex-dag1mb4.msg.corp.akamai.com ([172.27.6.134]) with mapi id 15.00.1473.003; Wed, 20 Mar 2019 19:41:07 -0500
From: "Holland, Jake" <jholland@akamai.com>
To: Greg White <g.white@CableLabs.com>
CC: tsvwg IETF list <tsvwg@ietf.org>, 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: AQHU319APuOfBca3V0qgUBmVQgtvQqYVHUKA
Date: Thu, 21 Mar 2019 00:41:06 +0000
Message-ID: <39359CD0-F9DB-4C49-88D9-A9604A01F416@akamai.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> <FDA48F4C-415B-4B8E-9CC7-2AAAD4DC3BE8@cablelabs.com>
In-Reply-To: <FDA48F4C-415B-4B8E-9CC7-2AAAD4DC3BE8@cablelabs.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.17.0.190309
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.113.18]
Content-Type: text/plain; charset="utf-8"
Content-ID: <838477D9A22A0F40BA10AC20E75FAD52@akamai.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-20_14:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903210002
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-20_14:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903210003
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/bY_8PLEKIH9d3DcyIXn6PK0hU8U>
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 00:41:15 -0000
Hi Greg, On 2019-03-20, 13:55, "Greg White" <g.white@CableLabs.com> wrote: 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"). [JH] This is an interesting claim, and I'm eager to see how well it holds up under scrutiny and deployment. I guess I'm not sure what exactly "normal" means, but I would expect that there are a lot of cases that occur frequently in practice where tradeoffs have to be made between throughput, loss, and latency. I'm finding I struggle to nail down exactly what I expect from scenarios like a short-RTT L4S flow competing with a long-RTT L4S flow (from transit delay) and with a BBR flow, and likewise when a short and a long RTT L4S flow are competing with a bunch of independent slow-start flows, but if the L4S cases do indeed get a better throughput than SCE-based approaches under the wide variety of situations normal internet use can fall into, I think that would convince me it's optimizing all of them at once, and it's a mistake to call it focused on the latency use case. But for now, I hope you'll forgive a little bit of skepticism... I find this stuff complicated, and it's hard for me to put high confidence on some of the predictions. Best regards, Jake 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 _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
- 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