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/