Re: [tsvwg] draft-morton-tsvwg-sce: "Permitted ECN codepoint packet transitions"

Dave Taht <dave@taht.net> Thu, 14 November 2019 18:38 UTC

Return-Path: <dave@taht.net>
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 BD476120835 for <tsvwg@ietfa.amsl.com>; Thu, 14 Nov 2019 10:38:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 f6ZZdamZvc4x for <tsvwg@ietfa.amsl.com>; Thu, 14 Nov 2019 10:38:24 -0800 (PST)
Received: from mail.taht.net (mail.taht.net [IPv6:2a01:7e00:e000:2d4:f00f:f00f:b33b:b33b]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4B6B120123 for <tsvwg@ietf.org>; Thu, 14 Nov 2019 10:38:23 -0800 (PST)
Received: from dancer.taht.net (c-73-170-84-247.hsd1.ca.comcast.net [73.170.84.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id EF85A21B1C; Thu, 14 Nov 2019 18:38:20 +0000 (UTC)
From: Dave Taht <dave@taht.net>
To: G Fairhurst <gorry@erg.abdn.ac.uk>
Cc: tsvwg@ietf.org
References: <201911141350.xAEDo99J048928@gndrsh.dnsmgr.net> <CADVnQynGEEmt2vYEX5e=bA9YW+mHpSJ7Z3W9K4nSfv_gk_Svwg@mail.gmail.com> <5DCD9D37.3000904@erg.abdn.ac.uk>
Date: Thu, 14 Nov 2019 10:38:17 -0800
In-Reply-To: <5DCD9D37.3000904@erg.abdn.ac.uk> (G. Fairhurst's message of "Fri, 15 Nov 2019 02:30:15 +0800")
Message-ID: <878soi482u.fsf@taht.net>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/NLOnktqdFK6-CxWPle2bKg10Rjk>
Subject: Re: [tsvwg] draft-morton-tsvwg-sce: "Permitted ECN codepoint packet transitions"
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, 14 Nov 2019 18:38:26 -0000

G Fairhurst <gorry@erg.abdn.ac.uk> writes:

> I would expect loss to be an important mechanism to deal with overload
> of a ECT(0) queue.

I expect loss to be an important mechanism to deal with overload of
ECT(0) *or* ECT(1).

In fact, I'd rather like it if transports considered a mixture of loss
and CE, in the SCE case, as an indication of grosser overload with a
correspondingly higher rate reduction.

This idea is not possible in the L4S case, sadly enough.

A bit more below.

>
> The observation that TCP senders received two signals - loss and
> CE-marking was the  important step behind RFC8511 to take advantage of
> any lower queuing delay that an ECN-capable AQM can provide, while
> accepting that bursts and other traffic can exceed the router's
> buffering and induce loss. That is somewhat different in L4S which
> seeks to keep a much lower queuing delay.
>
> Gory
>
>
> On 14/11/2019, 22:16, Neal Cardwell wrote:
>> On Thu, Nov 14, 2019 at 8:50 AM Rodney W. Grimes
>> <4bone@gndrsh.dnsmgr.net>  wrote:
>>> Hello tsvwg list members,
>>>
>>> It is our intent to ask for adoption by the TSVWG of draft-morton-tsvwg-sce
>>> (https://tools.ietf.org/html/draft-morton-tsvwg-sce-01) during the IETF/106
>>> Singapore TSVWG session.
>> One random thought: the draft-morton-tsvwg-sce-01 draft mentions:
>>
>>     Permitted ECN codepoint packet transitions by middleboxes are:
>>
>>             Not-ECT ->    Not-ECT (or drop)
>>             ECT     ->    ECT or SCE or CE
>>             SCE     ->    SCE or CE
>>             CE      ->    CE
>>
>> Presumably if the buffer space is full and an ECT-, SCE-, or CE-marked
>> packet arrives then that packet can be dropped. So presumably "drop"
>> is permitted from those codepoint states as well. (I see the point
>> that hopefully this will be rare for ECT/SCE/CE packets, but with
>> bursty connection arrivals it seems important to clarify that this is
>> possible.)
>>
>> Since a drop is not really an "ECN codepoint packet transition", and
>> can happen to any packet, perhaps "(or drop)" could be omitted from
>> the table, for clarity? And as a replacement, the text could mention
>> something about "drop" being a possibility for packets marked with any
>> of those ECN code points?

Good idea.

>>
>> best,
>> neal