Re: [tsvwg] Consensus call on ECT(1)
"K. K. Ramakrishnan" <kk@cs.ucr.edu> Mon, 18 May 2020 04:52 UTC
Return-Path: <kk@cs.ucr.edu>
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 5F8423A045B; Sun, 17 May 2020 21:52:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 GYcTGb2G08iy; Sun, 17 May 2020 21:52:09 -0700 (PDT)
Received: from send.cs.ucr.edu (send.cs.ucr.edu [169.235.30.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07D433A03FE; Sun, 17 May 2020 21:52:08 -0700 (PDT)
Received: from [192.168.1.117] (024-205-065-243.res.spectrum.com [24.205.65.243]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by send.cs.ucr.edu (Postfix) with ESMTPSA id 7753121A0B; Sun, 17 May 2020 21:52:07 -0700 (PDT)
To: tsvwg@ietf.org, tsvwg-chairs@ietf.org
From: "K. K. Ramakrishnan" <kk@cs.ucr.edu>
Message-ID: <0700ddb0-4efc-2be7-9fef-8c05d73b42c7@cs.ucr.edu>
Date: Sun, 17 May 2020 21:52:06 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/JHd1BJ5Pv3XwxDdho8oyTMpJA9M>
Subject: Re: [tsvwg] Consensus call on ECT(1)
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: Mon, 18 May 2020 04:52:11 -0000
This is in response to the request to share opinions on the topic of which option of ECT(1) is preferable. I would prefer the third option proposed in the email, and the following summarizes my view on the topic. -- It is good to see the IETF actively pursuing work to implement ECN in the Internet. While it is important to re-examine previous design decisions as technology, workloads, and application needs change, it is also necessary to verify that new designs are equally applicable over a wide dynamic range to accommodate use cases as the Internet continues to evolve. The current debate between L4S and SCE is helpful to bring forth to the forefront some of the key considerations that go into the design of the ECN control loop. The Internet is a diverse environment with widely varying, dynamic conditions, especially with regard to bandwidth and latency, and congestion control continues to have to strike a balance across multiple considerations. One of the critical aspects in congestion control is the need to be able to tolerate large round-trip delays in the Internet. Using the instantaneous queue as a main input to signal congestion is helpful when the feedback delays are quite small (relative to the buffer capacity in the routers and the packet arrival rate dynamics), but (as I found out at the beginning of my work on ECN in the mid-1980s) it is much more difficult to control congestion and have reasonable individual flow behavior when feedback delays get substantially larger. Active queue management techniques have been studied for a long time as a way to overcome this, in conjunction with a congestion signal that is not dependent on the highly varying, transient behavior of the instantaneous queue. Additionally, congestion control has an almost equally important goal of maintaining fairness as far as possible across flows that have diverse characteristics. We all recognize that there is some level of RTT-unfairness with the way TCP congestion control operates. While the specific fairness goal to be achieved has been (and probably will continue to be) debated, it is very helpful to not exacerbate the level of RTT-unfairness we observe now, with the new designs. Additionally, it is important to be robust to loss of packets that carry feedback information for congestion control. The considerations that went into the design of RFC 3168, including backwards compatibility to existing loss-based congestion control and providing the appropriate incentives, and avoiding dis-incentives, for adoption of ECN, may or may not apply as strongly to the current decision making. Nonetheless, a design that seeks to redo an important mechanism such as congestion control, that impacts so many, should carefully consider the issue of backwards compatibility to existing congestion control mechanisms that have been so widely deployed. I would suggest that we carefully look at the existing proposals and require careful demonstration, through evaluations, across all these dimensions. Some additional analysis and evaluation appear to be needed. A specific suggestion is to have emulations/simulations and experiments with implementations that carefully evaluate and successfully demonstrate reasonably stable throughput for long-lived flows and responsive to short-lived flows, adequate link utilization, and control the queue to mitigate congestion-induced delays and fairness (intra-protocol and inter-protocol) across connections with long and short RTT flows. Particularly critical is the need to be able to tolerate large RTTs that are representative of what we see on the Internet. This will help us understand the fundamental characteristics of the individual proposals and their backward compatibility. -- Thanks, K. K. Ramakrishnan -- K. K. Ramakrishnan Professor Dept. of Computer Science and Engineering University of California, Riverside Rm. 332, Winston Chung Hall Tel: (951) 827-2480 Web Page: http://www.cs.ucr.edu/~kk/
- [tsvwg] Consensus call on ECT(1) Wesley Eddy
- Re: [tsvwg] Consensus call on ECT(1) Greg White
- Re: [tsvwg] Consensus call on ECT(1) Jonathan Morton
- Re: [tsvwg] Consensus call on ECT(1) Steven Blake
- Re: [tsvwg] Consensus call on ECT(1) Sebastian Moeller
- Re: [tsvwg] Consensus call on ECT(1) Jeremy Harris
- Re: [tsvwg] Consensus call on ECT(1) Smith, Kevin, Vodafone Group
- Re: [tsvwg] Consensus call on ECT(1) Roland Bless
- Re: [tsvwg] Consensus call on ECT(1) Neal Cardwell
- Re: [tsvwg] Consensus call on ECT(1) Mirja Kuehlewind
- Re: [tsvwg] Consensus call on ECT(1) Anders Bloom
- Re: [tsvwg] Consensus call on ECT(1) Finkelstein, Jeff (CCI-Atlanta)
- Re: [tsvwg] Consensus call on ECT(1) Tommy Pauly
- Re: [tsvwg] Consensus call on ECT(1) De Schepper, Koen (Nokia - BE/Antwerp)
- Re: [tsvwg] Consensus call on ECT(1) C. M. Heard
- Re: [tsvwg] Consensus call on ECT(1) Uma Chunduri
- Re: [tsvwg] Consensus call on ECT(1) Ruediger.Geib
- Re: [tsvwg] Consensus call on ECT(1) Kyle Rose
- Re: [tsvwg] Consensus call on ECT(1) Black, David
- Re: [tsvwg] Consensus call on ECT(1) Holland, Jake
- Re: [tsvwg] Consensus call on ECT(1) Ozer, Sebnem
- [tsvwg] 3) "There is a specific test or tests I n… Dave Taht
- Re: [tsvwg] Consensus call on ECT(1) Ranganathan, Ram
- Re: [tsvwg] Consensus call on ECT(1) Paul Vixie
- Re: [tsvwg] Consensus call on ECT(1) Bob Briscoe
- Re: [tsvwg] Consensus call on ECT(1) Adi Masputra
- Re: [tsvwg] Consensus call on ECT(1) Asad Sajjad Ahmed
- Re: [tsvwg] Consensus call on ECT(1) Christoph Paasch
- Re: [tsvwg] Consensus call on ECT(1) Scheffenegger, Richard
- Re: [tsvwg] Consensus call on ECT(1) Lars Eggert
- Re: [tsvwg] Consensus call on ECT(1) Tilmans, Olivier (Nokia - BE/Antwerp)
- Re: [tsvwg] Consensus call on ECT(1) Andreas Petlund
- Re: [tsvwg] Consensus call on ECT(1) Rodney W. Grimes
- Re: [tsvwg] Consensus call on ECT(1) Jana Iyengar
- Re: [tsvwg] Consensus call on ECT(1) Joakim Misund
- Re: [tsvwg] Consensus call on ECT(1) Pete Heist
- Re: [tsvwg] Consensus call on ECT(1) Stuart Cheshire
- Re: [tsvwg] Consensus call on ECT(1) Sebastian Moeller
- Re: [tsvwg] Consensus call on ECT(1) Vividh Siddha
- Re: [tsvwg] Consensus call on ECT(1) David Pullen
- Re: [tsvwg] Consensus call on ECT(1) Campos, Angel, Vodafone Spain
- Re: [tsvwg] Consensus call on ECT(1) Flinck, Hannu (Nokia - FI/Espoo)
- Re: [tsvwg] Consensus call on ECT(1) Karthik Sundaresan
- Re: [tsvwg] Consensus call on ECT(1) Praveen Balasubramanian
- Re: [tsvwg] Consensus call on ECT(1) philip.eardley
- Re: [tsvwg] Consensus call on ECT(1) Tom Henderson
- Re: [tsvwg] Consensus call on ECT(1) Dave Taht
- Re: [tsvwg] Consensus call on ECT(1) K. K. Ramakrishnan
- Re: [tsvwg] Consensus call on ECT(1) Liyizhou
- Re: [tsvwg] Consensus call on ECT(1) Dan Siemon
- Re: [tsvwg] Consensus call on ECT(1) Mohit P. Tahiliani
- [tsvwg] More testing (was: Consensus call on ECT(… Bob Briscoe
- Re: [tsvwg] Consensus call on ECT(1) Roland Bless
- Re: [tsvwg] Consensus call on ECT(1) Mikael Abrahamsson
- Re: [tsvwg] Consensus call on ECT(1) Steven Blake