Discussion of explicit congestion notification's impact on the Internet
 help / color / mirror / Atom feed
From: Dave Taht <dave.taht@gmail.com>
To: bloat <bloat@lists.bufferbloat.net>,
	ECN-Sane <ecn-sane@lists.bufferbloat.net>,
	 Make-Wifi-fast <make-wifi-fast@lists.bufferbloat.net>
Subject: [Ecn-sane] Fwd: [NetDev-People] 0x14: nutsnbolts, What to do with 1/2 a bit? L4S, SCE, or ?
Date: Mon, 10 Feb 2020 17:59:06 -0800	[thread overview]
Message-ID: <CAA93jw7aMB4TV8pkie9YMNHbHUCvrSaR_jLGU3eQNHWsH9+=vw@mail.gmail.com> (raw)
In-Reply-To: <c5e9bc70.AMYAABcN9xAAAAAAAAAAAG3K_mQAAYCsBU0AAAAAAAwWzABePsYa@mailjet.com>

---------- Forwarded message ---------
From: Jamal Hadi Salim via people <people@netdevconf.info>
Date: Sat, Feb 8, 2020 at 6:30 AM
Subject: [NetDev-People] 0x14: nutsnbolts, What to do with 1/2 a bit?
L4S, SCE, or ?
To: people <people@netdevconf.org>
Cc: <prog-committee-0x14@netdevconf.info>



Imagine you have only one more bit left in the world! Scratch
that. Imagine there is only a half bit left in the world.
Then imagine there are multiple causes vying for this half bit.
Who would you give it to and why?

Yes, these things happen;-> A lot easier when it is between developers
and a lot harder when it is to decide a standard that shall be cast
in stone. The Internet Engineering Task Force (ietf) Transport Area
Working Group (tsvwg) has such a struggle going.
There are presently 2 proposals before for the last unused code point
in the IPv4/6 header - one by the Low Latency Low Loss Scalable
throughput (L4S) folks (see Netdev 0x13 for L4S talks) and another
from the Some Congestion Experienced (SCE) folks.

In this talk, Rodney Grimes will describe the two solutions and their
prototype kernel implementations; what changes are made to both TCP and
IP layers, etc.

Rod is then going to pose the $1M question and solicit feedback:
is one approach better than the other or do we need a new outlook?

More info:
https://netdevconf.info/0x14/session.html?talk-what-to-do-with-half-a-bit-L4S-SCE-or-what

Reminder, registration is now open and early bird is still in effect.
https://netdevconf.info/0x14/registration.html

DT> It's more of a multi-billion dollar question, in my mind. And the
jury's still out as to where this works or not. Certainly on wifi I
don't see much benefit to anything more than rfc3168 at this point,
and would have liked far more folk to have been turning it on that
just apple to sort the bugs out. But I do concede that either SCE or
L4S style signalling has some benefit in the DC. In between, on other
tech, danged if I know. I'm really looking forward to the mmwave preso
also at this netdevconf, as the first exploration of what the internet
looks like at higher, flaky frequencies. I keep hoping starlink will
present somewhere as well.

There were (from my perspective) worrying things about slow
convergence times, gross rtt-unfairness in either approach in the last
set of l4S vs SCE  benchmarks I saw, and I keep hoping for a published
rrul test.

https://github.com/heistp/sce-l4s-bakeoff#scenario-3

To what little extent I've focused on this over the past year, was to
try and get a grip on the size of the RFC3168 and dctcp style
deployments, and to try and get a grip on how L4S style traffic would
actually look like in relation to the kinds of traffic I care more
about. I look forward to an update. and there are a remarkable number
of other presentations about advanced congestion control techniques at
this conference. I wasn't planning to go... still might not... but if
y'all do, try and catch the below talk.

I'd certainly like more folk to be experimenting with these two ideas
before they are cast in stone.


cheers,
jamal
_______________________________________________
people mailing list
people@netdevconf.org
https://lists.netdevconf.info/cgi-bin/mailman/listinfo/people


--
Make Music, Not War

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-435-0729

           reply	other threads:[~2020-02-11  1:59 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <c5e9bc70.AMYAABcN9xAAAAAAAAAAAG3K_mQAAYCsBU0AAAAAAAwWzABePsYa@mailjet.com>]

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

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

  git send-email \
    --in-reply-to='CAA93jw7aMB4TV8pkie9YMNHbHUCvrSaR_jLGU3eQNHWsH9+=vw@mail.gmail.com' \
    --to=dave.taht@gmail.com \
    --cc=bloat@lists.bufferbloat.net \
    --cc=ecn-sane@lists.bufferbloat.net \
    --cc=make-wifi-fast@lists.bufferbloat.net \
    /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