IETF Logo Mail Archive

Re: [tsvwg] Chairs slides for interim meeting

"Rodney W. Grimes" <ietf@gndrsh.dnsmgr.net> Thu, 20 February 2020 01:59 UTC

Return-Path: <ietf@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 427721201DB for <tsvwg@ietfa.amsl.com>; Wed, 19 Feb 2020 17:59:44 -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.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 gAU9a2T5koAH for <tsvwg@ietfa.amsl.com>; Wed, 19 Feb 2020 17:59:42 -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 CEC6A12001B for <tsvwg@ietf.org>; Wed, 19 Feb 2020 17:59:42 -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 01K1xeMZ071858; Wed, 19 Feb 2020 17:59:40 -0800 (PST) (envelope-from ietf@gndrsh.dnsmgr.net)
Received: (from ietf@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 01K1xeNr071857; Wed, 19 Feb 2020 17:59:40 -0800 (PST) (envelope-from ietf)
From: "Rodney W. Grimes" <ietf@gndrsh.dnsmgr.net>
Message-Id: <202002200159.01K1xeNr071857@gndrsh.dnsmgr.net>
In-Reply-To: <MN2PR19MB4045C6C75E784CEC885797C583100@MN2PR19MB4045.namprd19.prod.outlook.com>
To: "Black, David" <David.Black@dell.com>
Date: Wed, 19 Feb 2020 17:59:40 -0800
CC: "tsvwg@ietf.org" <tsvwg@ietf.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/5nfR0YMESjUTbOF4shpEJ47Eks0>
Subject: Re: [tsvwg] Chairs slides for interim meeting
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, 20 Feb 2020 01:59:44 -0000

David,
	A comment in line below about your Hint to RFC 4774.

> I've posted the chairs slides for the interim meeting on how we plan (hope?) to make progress in the interim meeting and at the Vancouver meeting.  They focus on ECT(1) usage.
> 
> These slides and the rest of the materials for the interim meeting are (and will be) posted here: https://datatracker.ietf.org/meeting/interim-2020-tsvwg-01/session/tsvwg
> 
> Hint: RFC 4774 "Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field" is relevant background, especially Section 4.3 (Option 3:  Friendly Coexistence with Competing Traffic).

In reading RFC 4774 Section 4.3 at paragraph 9 we find:
   A requirement for compatibility with end-nodes using default ECN is
   that if a packet that *could* be using default semantics is marked
   with the ECN codepoint "00", this marking must not be changed to
   "01", "10", or "11" in the network.  This prevents the packet from
   being represented incorrectly to a default-ECN router downstream as
   ECN-Capable.  Similarly, if a packet that *could* be using default
   semantics is marked with the ECN codepoint "01", then this codepoint
   should not be changed to "10" in the network (and a "10" codepoint
   should not be changed to "01").  This requirement is necessary to
   avoid interference with the transport protocol's use of the ECN nonce
   [RFC3540].

For this purposes of this "Hint" can we consider that paragraph
to be stricken since RFC3540 and ECN nonce have been made historical
in scope?

Further I note that this RFC and BCP does not have an update to it
that would make the above paragraph obsolete, should something be
done about that?  An errata?


Thanks,
Rod

> Thanks, --David (with apologies for extending the IETF practice of just-in-time slide preparation)
> ----------------------------------------------------------------
> David L. Black, Sr. Distinguished Engineer, Dell EMC
> Dell Technologies, Infrastructure Systems Group
> 176 South St., Hopkinton, MA  01748
> +1 (774) 350-9323<tel:+17743509323>           Mobile: +1 (978) 394-7754<tel:+19783947754>
> David.Black@dell.com<mailto:David.Black@dell.com>
> ----------------------------------------------------------------
-- 
Rod Grimes                                                 rgrimes@freebsd.org

v2.23.0 | Report a Bug | By Email