Re: [tsvwg] Chairs slides for interim meeting
"Rodney W. Grimes" <ietf@gndrsh.dnsmgr.net> Thu, 20 February 2020 03:02 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 2196812011F for <tsvwg@ietfa.amsl.com>; Wed, 19 Feb 2020 19:02:16 -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 U8v6jexaw0Sr for <tsvwg@ietfa.amsl.com>; Wed, 19 Feb 2020 19:02:14 -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 9B6FB12008A for <tsvwg@ietf.org>; Wed, 19 Feb 2020 19:02:14 -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 01K32BtR072091; Wed, 19 Feb 2020 19:02:11 -0800 (PST) (envelope-from ietf@gndrsh.dnsmgr.net)
Received: (from ietf@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 01K32BQs072090; Wed, 19 Feb 2020 19:02:11 -0800 (PST) (envelope-from ietf)
From: "Rodney W. Grimes" <ietf@gndrsh.dnsmgr.net>
Message-Id: <202002200302.01K32BQs072090@gndrsh.dnsmgr.net>
In-Reply-To: <202002200159.01K1xeNr071857@gndrsh.dnsmgr.net>
To: "Rodney W. Grimes" <ietf@gndrsh.dnsmgr.net>
Date: Wed, 19 Feb 2020 19:02:11 -0800
CC: "Black, David" <David.Black@dell.com>, "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/G0O0Rb0frcZb5GZRP6K_29bzOCw>
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 03:02:16 -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? Correction, last 2 sentences stricken, not the whole paragraph. > 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 > > -- Rod Grimes rgrimes@freebsd.org
- [tsvwg] Chairs slides for interim meeting Black, David
- Re: [tsvwg] Chairs slides for interim meeting alex.burr@ealdwulf.org.uk
- Re: [tsvwg] Chairs slides for interim meeting Black, David
- Re: [tsvwg] Chairs slides for interim meeting Rodney W. Grimes
- Re: [tsvwg] Chairs slides for interim meeting Rodney W. Grimes
- Re: [tsvwg] Chairs slides for interim meeting Black, David