Subject: [tsvwg] Chairs slides for interim meeting

From: "Black, David" <[email-masked]>
Date: Wed, 19 Feb 2020 22:03:24 +0000

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).

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>
[email-masked]<mailto:[email-masked]>
----------------------------------------------------------------

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 19 Feb 2020 23:21:03 +0000 (UTC)

David, 
 one question in advance since I won't be at the meeting:
The slides say "Choose exactly one, not both". Why 'exactly one', not 'at most one'? Should not both proposals need to put a positive case,
as well as convincing us that they don't break the internet? Since this is the last codepoint, a given case may not be sufficient to use it up; and therefore both proposals may fail.

Alex

On Wednesday, February 19, 2020, 10:28:34 PM GMT, Black, David <[email-masked]> wrote: 

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.

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).

+1 (774) 350-9323           Mobile: +1 (978) 394-7754

[email-masked]

---

From: "Black, David" <[email-masked]>
Date: Thu, 20 Feb 2020 00:06:50 +0000

Alex,

Thanks for looking at the slides.

Point taken - not choosing either is a possible outcome (albeit, unlikely, IMHO), but "not both" is the more important point.   I'll revise the slide accordingly.

Also please do note that a decision on the usage of ECT(1) may well outlast the initial proposal to use it (L4S or SCE), as if such a proposal goes forward but does not achieve widespread deployment/usage, it may still leave behind a fair amount of "running code" that knows whether ECT(1) is an input or an output.  Such "running code" would make it harder to flip ECT(1) to the other role in the future.

Thanks, --David

> -----Original Message-----
> From: [email-masked] <[email-masked]>
> Sent: Wednesday, February 19, 2020 6:21 PM
> To: [email-masked]; Black, David
> Subject: Re: [tsvwg] Chairs slides for interim meeting
> 
> 
> [EXTERNAL EMAIL]
> 
> David,
> The slides say "Choose exactly one, not both". Why 'exactly one', not 'at
> most one'? Should not both proposals need to put a positive case,
> as well as convincing us that they don't break the internet? Since this is the
> last codepoint, a given case may not be sufficient to use it up; and therefore
> both proposals may fail.
> 
> Alex
> 
> 
> 
> 
> 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).
> 
> 
>

---

From: "Rodney W. Grimes" <[email-masked]>
Date: Wed, 19 Feb 2020 17:59:40 -0800 (PST)

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

> 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 T…

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

-- 
Rod Grimes                                                 [email-masked]

---

From: "Rodney W. Grimes" <[email-masked]>
Date: Wed, 19 Feb 2020 19:02:11 -0800 (PST)

> to be stricken since RFC3540 and ECN nonce have been made historical

Correction, last 2 sentences stricken, not the whole paragraph.

---

From: "Black, David" <[email-masked]>
Date: Thu, 20 Feb 2020 13:49:46 +0000

Yes, the ECN Nonce is no longer relevant.  RFC 8311 (which is an IETF consensus document) states that the RFC:

   o  Declares that the ECN nonce experiment [RFC3540] has concluded and
      notes the absence of widespread deployment.

Applying errata to one or both RFCs (4774 and 8311) seems to be a suitable means of dealing with this situation.

Thanks, --David

> From: Rodney W. Grimes <[email-masked]>
> Sent: Wednesday, February 19, 2020 10:02 PM
> To: Rodney W. Grimes
> Cc: Black, David; [email-masked]
> > > 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
> > > 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