> On 28 Apr, 2020, at 10:43 pm, Black, David <david.bl...@dell.com> wrote: > > And I also noted this at the end of the meeting: “queue protection that > might apply the disincentive” > > That would send cheaters to the L4S conventional queue along with all the > other queue-building traffic.
Alas, we have not yet seen an integrated implementation of the queue protection mechanism, so that we can test its effectiveness. I think it is part of the extra evidence that would be needed before a decision could be taken in favour of using ECT(1) as an input. I would also note in this context that mere volume of data, or length of development, are not marks that should be taken in favour of a proposal. The relevance, quality, thoroughness and results of data collection must be carefully evaluated, and it could easily be argued that a lengthy development cycle that still has not produced reliable results should be retired, to avoid throwing good money after bad. The fact that we were able to find serious problems with the (only?) reference implementation of L4S using a relatively small, but independently selected test suite does not lend confidence in its maturity. Reputable engineers know that it is necessary to establish a robust design first. Only then can a robust implementation be hoped for. It is the basic design decision, over the semantics of each ECN codepoint, that we were trying to discuss yesterday. I'm not certain that everyone in the room understood that. - Jonathan Morton _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
