IETF Logo Mail Archive

Re: [tsvwg] New Version Notification for draft-morton-taht-tsvwg-sce-00.txt

Michael Welzl <michawe@ifi.uio.no> Mon, 11 March 2019 09:39 UTC

Return-Path: <michawe@ifi.uio.no>
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 2194D12E036 for <tsvwg@ietfa.amsl.com>; Mon, 11 Mar 2019 02:39:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 gSAnnm4R5NKK for <tsvwg@ietfa.amsl.com>; Mon, 11 Mar 2019 02:39:44 -0700 (PDT)
Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (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 EAF96127968 for <tsvwg@ietf.org>; Mon, 11 Mar 2019 02:39:43 -0700 (PDT)
Received: from mail-mx10.uio.no ([129.240.10.27]) by mail-out01.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from <michawe@ifi.uio.no>) id 1h3HPJ-0007lj-QX; Mon, 11 Mar 2019 10:39:41 +0100
Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx10.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.91) (envelope-from <michawe@ifi.uio.no>) id 1h3HPJ-0003ZP-3j; Mon, 11 Mar 2019 10:39:41 +0100
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Michael Welzl <michawe@ifi.uio.no>
In-Reply-To: <87h8canrc6.fsf@taht.net>
Date: Mon, 11 Mar 2019 10:39:40 +0100
Cc: tsvwg@ietf.org, Jonathan Morton <chromatix99@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <3CA247DE-4CA2-46CB-8367-E96889D808A8@ifi.uio.no>
References: <155226671763.31131.7874324055612031095.idtracker@ietfa.amsl.com> <87h8canrc6.fsf@taht.net>
To: Dave Taht <dave@taht.net>
X-Mailer: Apple Mail (2.3445.9.1)
X-UiO-SPF-Received: Received-SPF: neutral (mail-mx10.uio.no: 129.240.68.135 is neither permitted nor denied by domain of ifi.uio.no) client-ip=129.240.68.135; envelope-from=michawe@ifi.uio.no; helo=boomerang.ifi.uio.no;
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 34D793B1C49EAB5F7782F1D4D1E7C4659CE48914
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/37DIBu9PCewy-oksPRSdFFrdxto>
Subject: Re: [tsvwg] New Version Notification for draft-morton-taht-tsvwg-sce-00.txt
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, 11 Mar 2019 09:39:46 -0000

Hi,

Regarding this paragraph:

***
   The underlying cause is the very sharp "multiplicative decrease"
   reaction required of transport protocols to congestion signalling
   (whether that be packet loss or CE marks), which tends to leave the
   congestion window significantly smaller than the ideal BDP when
   triggered at only slightly above the ideal value.  The availability
   of this sharp response is required to assure network stability (AIMD
   principle), but there is presently no standardised and backwards-
   compatible means of providing a less drastic signal.
***

FWIW, TCP Alternative Backoff with ECN (ABE), RFC 8511, tries to address exactly that problem without requiring an extra code point.

The underlying logic is: when ECN is signalled, chances are that there's an AQM algorithm in place, and the queue is probably short - hence the very sharp response is probably not appropriate.

Cheers,
Michael


> On 11 Mar 2019, at 02:16, Dave Taht <dave@taht.net> wrote:
> 
> 
> I think this gets the procedure right for submittal here.
> 
> internet-drafts@ietf.org writes:
> 
>> A new version of I-D, draft-morton-taht-tsvwg-sce-00.txt
>> has been successfully submitted by David M. Täht and posted to the
>> IETF repository.
>> 
>> Name:		draft-morton-taht-tsvwg-sce
>> Revision:	00
>> Title:		The Some Congestion Experienced ECN Codepoint
>> Document date:	2019-03-10
>> Group:		Individual Submission
>> Pages:		7
>> URL:            https://www.ietf.org/internet-drafts/draft-morton-taht-tsvwg-sce-00.txt
>> Status:         https://datatracker.ietf.org/doc/draft-morton-taht-tsvwg-sce/
>> Htmlized:       https://tools.ietf.org/html/draft-morton-taht-tsvwg-sce-00
>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-morton-taht-tsvwg-sce
>> 
>> 
>> Abstract:
>>   This memo reclassifies ECT(1) to be an early notification of
>>   congestion on ECT(0) marked packets, which can be used by AQM
>>   algorithms and transports as an earlier signal of congestion than CE.
>>   It is a simple, transparent, and backward compatible upgrade to
>>   existing IETF-approved AQMs, RFC3168, and nearly all congestion
>>   control algorithms.
>> 
>> 
>> 
>> 
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>> 
>> The IETF Secretariat
>

v2.23.0 | Report a Bug | By Email