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

"Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net> Fri, 15 November 2019 16:14 UTC

Return-Path: <freebsd@gndrsh.dnsmgr.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 02605120801 for <tsvwg@ietfa.amsl.com>; Fri, 15 Nov 2019 08:14:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.498
X-Spam-Level:
X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.4, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no 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 JFtkW3vX4xps for <tsvwg@ietfa.amsl.com>; Fri, 15 Nov 2019 08:14:32 -0800 (PST)
Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE2C6120073 for <tsvwg@ietf.org>; Fri, 15 Nov 2019 08:14:31 -0800 (PST)
Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id xAFGEPAM053415; Fri, 15 Nov 2019 08:14:25 -0800 (PST) (envelope-from freebsd@gndrsh.dnsmgr.net)
Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id xAFGEOLX053414; Fri, 15 Nov 2019 08:14:24 -0800 (PST) (envelope-from freebsd)
From: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net>
Message-Id: <201911151614.xAFGEOLX053414@gndrsh.dnsmgr.net>
In-Reply-To: <CADVnQy=Urrgj8znECjeCs0g5tuz0EGYCPFBmae4y2CKLYzX8Rw@mail.gmail.com>
To: Neal Cardwell <ncardwell=40google.com@dmarc.ietf.org>
Date: Fri, 15 Nov 2019 08:14:24 -0800
CC: Jonathan Morton <chromatix99@gmail.com>, G Fairhurst <gorry@erg.abdn.ac.uk>, tsvwg IETF list <tsvwg@ietf.org>
Reply-To: rgrimes@freebsd.org
X-Mailer: ELM [version 2.4ME+ PL121h (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/V10wuvgxg4nKP43fFBO3Na43smU>
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: Fri, 15 Nov 2019 16:14:33 -0000

[ Charset UTF-8 unsupported, converting... ]
> On Thu, Nov 14, 2019 at 1:35 PM Jonathan Morton <chromatix99@gmail.com> wrote:
> >
> > I think the possibility of packet loss is inherently implied in the best effort nature of IP routing.  The previous wording did include an explicit reference to dropping each class of packet, but I thought it was unnecessarily verbose like that.
> >
> > Is an explicit reference to dropping needed here at all?  If so, I may move it to a separate sentence and remove it from the table altogether.
> 
> Since this is a table summarizing "codepoint packet transitions", IMHO
> a mention of "(or drop)" is not needed in the table, and just confuses
> things if "(or drop)" is only listed in one row when it really applies
> to all rows.
> 
> IMHO an explicit reference to dropping is not needed in that passage.
> But if others think it's necessary, then moving it to a separate
> sentence and removing it from the table altogether sounds great.

I can agree with this as long as the table is called "codepoint
packet transitions", but what an implementation is interested in
is the state machine transitions, and that state machine is going
to have a drop node.

So you could call this table "packet state transitions", and
use the "or drop", or you can do what Neal outlines above,
either works for me as good solutions to this slightly unclear
table.

> best,
> neal
-- 
Rod Grimes                                                 rgrimes@freebsd.org