Cake - FQ_codel the next generation
 help / color / mirror / Atom feed
From: "Holland, Jake" <jholland@akamai.com>
To: Mikael Abrahamsson <swmike@swm.pp.se>,
	Jonathan Morton <chromatix99@gmail.com>
Cc: Cake List <cake@lists.bufferbloat.net>,
	"ecn-sane@lists.bufferbloat.net" <ecn-sane@lists.bufferbloat.net>,
	"codel@lists.bufferbloat.net" <codel@lists.bufferbloat.net>,
	bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] The "Some Congestion Experienced" ECN codepoint - a new internet draft -
Date: Mon, 11 Mar 2019 16:14:28 +0000	[thread overview]
Message-ID: <663DE707-E685-4D84-BE4F-26C88F479057@akamai.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1903111044210.3161@uplift.swm.pp.se>

+1, I agree SCE on its own isn't enough.

Before I support adoption as a proposed standard I'd want real-world tests
demonstrating the value.  I believe SCE has potential similar to L4S by
providing a similar fine-grained congestion signal, and that it does so
in a much cleaner way.

But there's a big gap between "has potential" and "has proven benefit" that
I'd want to see filled before it's an RFC.

That said, I would like to see experiments go forward, and I would like to
see this become an active draft that a wg owns, so that if the experiments
do prove there's utility that can be captured, it has a good path forward.

I have concerns about L4S, and so my relief is about seeing a cleaner
(and backward compatible!) proposal that does something that to me looks
like a very similar effect.  And I would very much like to see a bakeoff
of some sort before committing ECT(1) to the use of L4S, since it seems
to me there are some ugly problems down that road.

Cheers,
Jake

On 2019-03-11, 02:47, "Mikael Abrahamsson" <swmike@swm.pp.se> wrote:

    On Mon, 11 Mar 2019, Jonathan Morton wrote:
    
    >> On 11 Mar, 2019, at 11:07 am, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
    >>
    >> Well, I am not convinced blowing the last codepoint on SCE has enough merit.
    >
    > I will make a stronger statement: I am convinced that blowing the last codepoint on L4S does *not* have enough merit.
    
    ... and I believe that blowing it on SCE doesn't have merit either.
    
    That's the entire thing why I am opposing the use of ECT(1) unless we're 
    *really* *really* *really* sure there is something we want to blow it on.
    
    Using it for SCE for me is marginal benefit compared to what ECT(1) could 
    be used for either. I think L4S is proposing enough novelty that it could 
    be used for that, but I'm open for other suggestions. SCE isn't enough.
    
    -- 
    Mikael Abrahamsson    email: swmike@swm.pp.se
    _______________________________________________
    Bloat mailing list
    Bloat@lists.bufferbloat.net
    https://lists.bufferbloat.net/listinfo/bloat
    


  parent reply	other threads:[~2019-03-11 16:14 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-10 18:04 [Cake] " Dave Taht
2019-03-10 18:53 ` Sebastian Moeller
2019-03-10 19:08 ` [Bloat] " Holland, Jake
2019-03-10 19:30   ` [Cake] " Jonathan Morton
2019-03-11  7:08     ` Mikael Abrahamsson
2019-03-11  7:35       ` Richard Scheffenegger
2019-03-11  7:54         ` Sebastian Moeller
2019-03-11  8:59         ` Jonathan Morton
2019-03-11  9:07           ` Mikael Abrahamsson
2019-03-11  9:10             ` Jonathan Morton
2019-03-11  9:47               ` Mikael Abrahamsson
2019-03-11 10:11                 ` [Cake] [Codel] " Dave Taht
2019-03-11 16:14                 ` Holland, Jake [this message]
2019-03-11 15:29             ` [Ecn-sane] " Holland, Jake
2019-03-11 16:13               ` [Cake] " Jonathan Morton
2019-03-11  7:43       ` [Cake] " Sebastian Moeller
2019-03-11  8:23         ` Mikael Abrahamsson
2019-03-13  4:39         ` David Lang
2019-03-10 21:11   ` Dave Taht
2019-03-10 21:28     ` Dave Taht
2019-03-10 21:49       ` Dave Taht
2019-03-10 22:37         ` [Ecn-sane] " Toke Høiland-Jørgensen
2019-03-11  3:23   ` [Cake] " Michael Richardson
2019-03-11  3:26     ` Dave Taht

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/cake.lists.bufferbloat.net/

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

  git send-email \
    --in-reply-to=663DE707-E685-4D84-BE4F-26C88F479057@akamai.com \
    --to=jholland@akamai.com \
    --cc=bloat@lists.bufferbloat.net \
    --cc=cake@lists.bufferbloat.net \
    --cc=chromatix99@gmail.com \
    --cc=codel@lists.bufferbloat.net \
    --cc=ecn-sane@lists.bufferbloat.net \
    --cc=swmike@swm.pp.se \
    /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