Subject: [tsvwg] closed L4S issue #20 on use of ECT(1)

From: Wesley Eddy <[email-masked]>
Date: Thu, 4 Jun 2020 13:35:36 -0400

This is just a note to let the WG know that in the TSVWG trac, I've 
closed L4S issue #20 on the use of ECT(1), based on the recent consensus 
call around this.

I plan to create threads in the next couple of days to discuss paths 
towards closure for some of the other issues as well, to see if there is 
agreement on what should be done.

---

From: Dave Taht <[email-masked]>
Date: Thu, 4 Jun 2020 11:20:20 -0700

> closed L4S issue #20 on the use of ECT(1), based on the recent consensus

I did not see consensus. What I saw was the principal inventor of ecn
(kk), the ns3 maintainer, myself and a few others,
calling for more testing. Others on the SCE front, voted for option 2.

Then there was a bunch of folk that had never participated on this
list before, voting.

-- 
"For a successful technology, reality must take precedence over public
relations, for Mother Nature cannot be fooled" - Richard Feynman

[email-masked] <Dave Täht> CTO, TekLibre, LLC Tel: 1-831-435-0729

---

From: Wesley Eddy <[email-masked]>
Date: Thu, 4 Jun 2020 14:33:58 -0400

> Then there was a bunch of folk that had never participated on this

We don't vote, and there never was a vote.  Many people with long 
histories of participation in this working group and others expressed 
their positions.  Some were sent offlist, which you would not have 
seen.  All 3 co-chairs and the ADs collaborated on evaluating the total 
set of inputs and deciding how to proceed. This was not done by counting 
a vote, so there should be no concern about that.

---

From: Dave Taht <[email-masked]>
Date: Thu, 4 Jun 2020 11:50:41 -0700

> a vote, so there should be no concern about that.

Well, I would have weighted the inputs, perhaps differently.

IMHO There really needs to be a ton more running code before getting
to rough consensus on this point. Seeing that
last batch of bugs (on vpns and on loss in the prague ll queue) show
up on the evening of the consensus call
should have been an eye opener for anyone here that still believes in
doing quality engineering.

I have no idea how much has been published based on faulty code at this point.

---

From: "Rodney W. Grimes" <[email-masked]>
Date: Fri, 5 Jun 2020 06:22:19 -0700 (PDT)

> We don't vote, and there never was a vote.? Many people with long 
> their positions.? Some were sent offlist, which you would not have 
> seen.? All 3 co-chairs and the ADs collaborated on evaluating the total 

What the chairs said, from my read of it, is that they are going to
go forward with L4S.  I did not see them declare ECT(1) as an input
being in consensus, and thus object to closing this issue as that
consenses is not in evidence.

L4S itself offers alternatives to use of ECT(1) and this issue is about
that selection even within the draft.  The issue may need reworded to
minimize references to SCE, but that does not remove the issue either.

Regards,
-- 
Rod Grimes                                                 [email-masked]

---

From: Sebastian Moeller <[email-masked]>
Date: Fri, 5 Jun 2020 17:35:00 +0200

Dear chairs,

I want to take this opportunity too highlight a section in https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-10#page-9
that in my opinion needs work in the light of Rodney's observation about the nature of the found consensus:

"2.  Consensus Choice of L4S Packet Identifier: Requirements

   This subsection briefly records the process that led to a consensus
   choice of L4S identifier, selected from all the alternatives in Appendix B..."

I have looked through a number of recent  meeting minutes and video recordings, and I can not find any explicit call for reaching consensus on the L4S identifier, 
Could someone just clue me in on the exact meeting this consensus was found or could the draft text adjusted to reflect the scope and the group that reached that consensus? 

Best Regards
	Sebastian 

> On Jun 5, 2020, at 15:22, Rodney W. Grimes <[email-masked]> wrote:
>