From: Jonathan Morton <chromatix99@gmail.com>
To: Bob Briscoe <ietf@bobbriscoe.net>
Cc: "Holland, Jake" <jholland@akamai.com>,
"David P. Reed" <dpreed@deepplum.com>,
Vint Cerf <vint@google.com>, tsvwg IETF list <tsvwg@ietf.org>,
bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104
Date: Thu, 21 Mar 2019 01:51:07 +0200 [thread overview]
Message-ID: <04E62EA7-82EF-4F1B-A86D-5A23CA3B190A@gmail.com> (raw)
In-Reply-To: <7e49b551-22e5-5d54-2a1c-69f53983d7e5@bobbriscoe.net>
> On 21 Mar, 2019, at 1:29 am, Bob Briscoe <ietf@bobbriscoe.net> wrote:
>
>> But more importantly, the L4S usage couples the minimized latency use
>> case to any possibility of getting a high fidelity explicit congestion
>> signal, so the "maximize throughput" use case can't ever get it.
> Eh? There's definitely a misunderstanding or a difference in terminology between us here. The whole point of using a congestion controller like DCTCP is so that flow rate can scale indefinitely with capacity. Van Jacobson actually noted that the original TCP was unscalable in a footnote to the tech report version of the SIGCOMM paper.
>
> The high fidelity congestion signal of what we call scalable congestion controllers (like DCTCP) is inversely proportional to the window. So as window scales up, the congestion signal scales down, so that their product remains constant. That means the number of ECN marks per RTT is scale-invariant. So the control signal remains just as tight at any scale.
If you'll indulge me for a moment, I'd like to lay out a compromise scenario where a lot of L4S' stated goals are still met.
There is no dualQ. There is an AQM at the bottleneck link, of unspecified type, which implements SCE. Assume that it produces CE marks like a conventional AQM, and also produces SCE marks like an L4S AQM produces CE.
A sender implements DCTCP-SCE, which is essentially Paced NewReno modified to subtract half of all acked data that was SCE-marked from its cwnd. (This is equivalent to the DCTCP algorithm with g=1 and an arbitrarily small measurement window, but acting on SCE instead of CE.) Any SCE mark also kicks it out of slow-start.
The means by which SCE information gets back to the sender is left vague for now; it's an orthogonal problem with several viable solutions.
What is missing from this scenario, from L4S' point of view? And why have I been able to describe it so succinctly?
- Jonathan Morton
next prev parent reply other threads:[~2019-03-20 23:51 UTC|newest]
Thread overview: 105+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <AM0PR07MB48198660539171737E4CCAB1E0730@AM0PR07MB4819.eurprd07.prod.outlook.com>
[not found] ` <d91a6a71-5898-9571-2a02-0d9d83839615@bobbriscoe.net>
2019-03-15 10:46 ` [Bloat] " Dave Taht
2019-03-15 13:01 ` Sebastian Moeller
2019-03-15 14:06 ` Dave Taht
2019-03-15 15:52 ` Sebastian Moeller
2019-03-15 17:01 ` [Bloat] [Ecn-sane] " David P. Reed
2019-03-15 17:45 ` Sebastian Moeller
2019-03-15 18:36 ` Mikael Abrahamsson
2019-03-15 19:23 ` Sebastian Moeller
2019-03-15 19:32 ` Jonathan Morton
2019-03-15 19:44 ` David P. Reed
2019-03-15 20:13 ` Jonathan Morton
2019-03-15 23:43 ` David P. Reed
2019-03-16 1:26 ` Jonathan Morton
2019-03-16 7:38 ` Sebastian Moeller
2019-03-16 18:56 ` Michael Richardson
2019-03-15 20:28 ` Jonathan Foulkes
2019-03-15 20:31 ` Dave Taht
2019-03-15 23:45 ` David P. Reed
2019-03-16 9:42 ` Michael Welzl
2019-03-16 10:08 ` Sebastian Moeller
2019-03-16 10:23 ` Nils Andreas Svee
2019-03-16 14:55 ` Jonathan Foulkes
2019-03-16 21:38 ` Holland, Jake
2019-03-16 21:57 ` Vint Cerf
2019-03-16 22:03 ` Dave Taht
2019-03-16 22:05 ` Holland, Jake
2019-03-17 18:07 ` David P. Reed
2019-03-17 18:05 ` Vint Cerf
2019-03-19 1:06 ` Bob Briscoe
2019-03-19 3:18 ` Dave Taht
2019-03-20 19:04 ` Holland, Jake
2019-03-20 19:58 ` Stephen Hemminger
2019-03-20 20:05 ` Holland, Jake
[not found] ` <5C9296E1.4010703@erg.abdn.ac.uk>
2019-03-20 20:00 ` [Bloat] [tsvwg] " Holland, Jake
2019-03-20 20:05 ` Jonathan Morton
2019-03-20 20:55 ` Greg White
2019-03-20 22:12 ` Sebastian Moeller
2019-03-20 22:31 ` Jonathan Morton
2019-03-20 22:56 ` Sebastian Moeller
2019-03-20 23:03 ` Jonathan Morton
2019-03-20 23:11 ` Holland, Jake
2019-03-20 23:28 ` Jonathan Morton
2019-03-21 8:15 ` [Bloat] [Ecn-sane] [tsvwg] " Mikael Abrahamsson
2019-03-21 8:31 ` Mikael Abrahamsson
2019-03-20 23:30 ` [Bloat] [tsvwg] [Ecn-sane] " Sebastian Moeller
2019-03-21 0:15 ` Holland, Jake
2019-03-21 0:41 ` Holland, Jake
2019-03-20 21:48 ` [Bloat] " Greg White
2019-03-20 21:56 ` Jonathan Morton
2019-03-20 22:38 ` Holland, Jake
2019-03-20 22:56 ` Greg White
2019-03-20 23:29 ` Bob Briscoe
2019-03-20 23:51 ` Jonathan Morton [this message]
2019-03-21 6:04 ` Bob Briscoe
2019-03-21 7:46 ` Jonathan Morton
2019-03-21 8:02 ` Bob Briscoe
2019-03-21 8:49 ` Bless, Roland (TM)
2019-03-21 13:24 ` Bob Briscoe
2019-03-22 12:53 ` Bless, Roland (TM)
2019-03-25 2:47 ` Bob Briscoe
2019-03-21 8:45 ` Sebastian Moeller
2019-03-24 20:15 ` alex.burr
2019-03-25 1:34 ` Bob Briscoe
2019-03-27 17:52 ` Alex Burr
2019-03-19 4:44 ` Greg White
2019-03-19 5:35 ` Jonathan Morton
2019-03-19 5:52 ` Greg White
2019-03-19 7:10 ` Jonathan Morton
2019-03-19 8:07 ` Sebastian Moeller
2019-03-19 8:50 ` Sebastian Moeller
2019-03-19 23:59 ` Dave Taht
2019-03-20 10:17 ` Sebastian Moeller
2019-03-16 22:03 ` Jonathan Morton
2019-03-16 22:09 ` Sebastian Moeller
2019-03-17 14:06 ` Mikael Abrahamsson
2019-03-17 17:37 ` Loganaden Velvindron
2019-03-17 17:40 ` Toke Høiland-Jørgensen
2019-03-17 17:44 ` Mikael Abrahamsson
2019-03-17 18:00 ` Dave Taht
2019-03-17 19:38 ` Rodney W. Grimes
2019-03-17 20:50 ` Luca Muscariello
2019-03-17 21:51 ` Toke Høiland-Jørgensen
2019-03-18 4:26 ` Mikael Abrahamsson
2019-03-16 4:04 ` Jonathan Morton
2019-03-16 4:51 ` Dave Taht
2019-03-15 18:07 ` Mikael Abrahamsson
2019-03-15 14:27 ` [Bloat] " Jonathan Morton
2019-03-15 14:44 ` Sebastian Moeller
2019-03-15 15:49 ` Jonathan Morton
2019-03-15 21:34 ` Wesley Eddy
2019-03-22 18:28 [Bloat] [Ecn-sane] " Victor Hou
2019-03-23 8:02 ` Roland Bless
2019-03-23 8:54 ` Luca Muscariello
2019-03-23 10:02 ` Mikael Abrahamsson
2019-03-23 15:03 ` Jonathan Morton
2019-03-23 19:52 ` Roland Bless
2019-03-23 15:19 ` Roland Bless
2019-03-23 17:16 ` Mikael Abrahamsson
2019-03-23 19:45 ` Roland Bless
2019-03-23 17:48 ` Michael Welzl
2019-03-23 18:31 ` Luca Muscariello
2019-03-23 18:40 ` Mikael Abrahamsson
2019-03-23 19:11 ` Michael Welzl
2019-03-23 21:04 ` Luca Muscariello
2019-03-23 19:55 ` Roland Bless
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=04E62EA7-82EF-4F1B-A86D-5A23CA3B190A@gmail.com \
--to=chromatix99@gmail.com \
--cc=bloat@lists.bufferbloat.net \
--cc=dpreed@deepplum.com \
--cc=ietf@bobbriscoe.net \
--cc=jholland@akamai.com \
--cc=tsvwg@ietf.org \
--cc=vint@google.com \
/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