General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: Jonathan Morton <chromatix99@gmail.com>
To: "Black, David" <David.Black@dell.com>
Cc: Luca Muscariello <muscariello@ieee.org>,
	Gorry Fairhurst <gorry@erg.abdn.ac.uk>,
	tsvwg IETF list <tsvwg@ietf.org>,
	bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] [tsvwg] my backlogged comments on the ECT(1) interim call
Date: Tue, 28 Apr 2020 22:59:03 +0300	[thread overview]
Message-ID: <151D6673-BD73-4687-8AD5-D8D1CEA87D16@gmail.com> (raw)
In-Reply-To: <MN2PR19MB404573D80E091855D83603A983AC0@MN2PR19MB4045.namprd19.prod.outlook.com>

> On 28 Apr, 2020, at 10:43 pm, Black, David <David.Black@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


  reply	other threads:[~2020-04-28 19:59 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-27 19:24 [Bloat] " Dave Taht
2020-04-28  8:53 ` Luca Muscariello
2020-04-28 17:12   ` Holland, Jake
2020-04-28 19:04     ` Luca Muscariello
     [not found]       ` <bad22a6b-698d-c85f-b829-6b5391833a1e@erg.abdn.ac.uk>
2020-04-28 19:38         ` [Bloat] [tsvwg] " Luca Muscariello
2020-04-28 19:43           ` Black, David
2020-04-28 19:59             ` Jonathan Morton [this message]
2020-04-28 20:33         ` Sebastian Moeller
2020-04-29  8:44       ` Rodney W. Grimes
2020-04-29  9:25         ` Luca Muscariello
2020-04-29  9:46           ` Jonathan Morton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=151D6673-BD73-4687-8AD5-D8D1CEA87D16@gmail.com \
    --to=chromatix99@gmail.com \
    --cc=David.Black@dell.com \
    --cc=bloat@lists.bufferbloat.net \
    --cc=gorry@erg.abdn.ac.uk \
    --cc=muscariello@ieee.org \
    --cc=tsvwg@ietf.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox