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
- [tsvwg] Requesting TSVWG adoption of SCE draft-mo… Rodney W. Grimes
- [tsvwg] draft-morton-tsvwg-sce: "Permitted ECN co… Neal Cardwell
- Re: [tsvwg] Requesting TSVWG adoption of SCE draf… De Schepper, Koen (Nokia - BE/Antwerp)
- Re: [tsvwg] draft-morton-tsvwg-sce: "Permitted EC… Dave Taht
- Re: [tsvwg] draft-morton-tsvwg-sce: "Permitted EC… G Fairhurst
- Re: [tsvwg] draft-morton-tsvwg-sce: "Permitted EC… Jonathan Morton
- Re: [tsvwg] draft-morton-tsvwg-sce: "Permitted EC… Dave Taht
- Re: [tsvwg] Requesting TSVWG adoption of SCE draf… Sebastian Moeller
- Re: [tsvwg] Requesting TSVWG adoption of SCE draf… G Fairhurst
- Re: [tsvwg] draft-morton-tsvwg-sce: "Permitted EC… Matt Mathis
- Re: [tsvwg] draft-morton-tsvwg-sce: "Permitted EC… Jonathan Morton
- Re: [tsvwg] draft-morton-tsvwg-sce: "Permitted EC… Neal Cardwell
- Re: [tsvwg] Requesting TSVWG adoption of SCE draf… Sebastian Moeller
- Re: [tsvwg] Requesting TSVWG adoption of SCE draf… Jonathan Morton
- Re: [tsvwg] Requesting TSVWG adoption of SCE draf… G Fairhurst
- Re: [tsvwg] draft-morton-tsvwg-sce: "Permitted EC… Rodney W. Grimes
- Re: [tsvwg] draft-morton-tsvwg-sce: "Permitted EC… Rodney W. Grimes
- Re: [tsvwg] Requesting TSVWG adoption of SCE draf… Roni Even (A)
- Re: [tsvwg] Requesting TSVWG adoption of SCE draf… De Schepper, Koen (Nokia - BE/Antwerp)
- Re: [tsvwg] Requesting TSVWG adoption of SCE draf… Dave Taht
- Re: [tsvwg] Requesting TSVWG adoption of SCE draf… Ingemar Johansson S
- Re: [tsvwg] Requesting TSVWG adoption of SCE draf… Bob Briscoe
- Re: [tsvwg] Requesting TSVWG adoption of SCE draf… Roni Even (A)
- Re: [tsvwg] Requesting TSVWG adoption of SCE draf… Holland, Jake
- Re: [tsvwg] Requesting TSVWG adoption of SCE draf… Scheffenegger, Richard
- Re: [tsvwg] Requesting TSVWG adoption of SCE draf… Jonathan Morton
- Re: [tsvwg] Requesting TSVWG adoption of SCE draf… Greg White
- Re: [tsvwg] Requesting TSVWG adoption of SCE draf… Scheffenegger, Richard
- Re: [tsvwg] Requesting TSVWG adoption of SCE draf… Black, David
- Re: [tsvwg] Requesting TSVWG adoption of SCE draf… Jonathan Morton
- Re: [tsvwg] Requesting TSVWG adoption of SCE draf… G Fairhurst
- Re: [tsvwg] Requesting TSVWG adoption of SCE draf… Kyle Rose
- Re: [tsvwg] Requesting TSVWG adoption of SCE draf… Luca Muscariello
- Re: [tsvwg] Requesting TSVWG adoption of SCE draf… Sebastian Moeller
- Re: [tsvwg] Requesting TSVWG adoption of SCE draf… Loganaden Velvindron
- Re: [tsvwg] Requesting TSVWG adoption of SCE draf… De Schepper, Koen (Nokia - BE/Antwerp)
- Re: [tsvwg] Requesting TSVWG adoption of SCE draf… Luca Muscariello
- Re: [tsvwg] Requesting TSVWG adoption of SCE draf… Ingemar Johansson S
- Re: [tsvwg] Requesting TSVWG adoption of SCE draf… Sebastian Moeller
- Re: [tsvwg] Requesting TSVWG adoption of SCE draf… Michael Welzl
- Re: [tsvwg] Requesting TSVWG adoption of SCE draf… Ingemar Johansson S
- Re: [tsvwg] Requesting TSVWG adoption of SCE draf… Jonathan Morton
- Re: [tsvwg] Requesting TSVWG adoption of SCE draf… Sebastian Moeller
- Re: [tsvwg] Requesting TSVWG adoption of SCE draf… Michael Welzl
- Re: [tsvwg] Requesting TSVWG adoption of SCE draf… Roland Bless