Discussion of explicit congestion notification's impact on the Internet
 help / color / mirror / Atom feed
From: Jonathan Morton <chromatix99@gmail.com>
To: Greg White <g.white@CableLabs.com>
Cc: "David P. Reed" <dpreed@deepplum.com>,
	Vint Cerf <vint@google.com>,
	"ecn-sane@lists.bufferbloat.net" <ecn-sane@lists.bufferbloat.net>,
	bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Ecn-sane] [Bloat] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104
Date: Tue, 19 Mar 2019 09:10:52 +0200	[thread overview]
Message-ID: <3C188730-DCD1-4359-AA19-F7526ECDF111@gmail.com> (raw)
In-Reply-To: <CB112812-F635-4DB5-A039-BE9423CE432E@cablelabs.com>

> On 19 Mar, 2019, at 7:52 am, Greg White <g.white@CableLabs.com> wrote:
> 
> L4S utilizes TCP Prague, which falls back to traditional congestion control if the bottleneck link doesn't provide isolation.  

You see, this is the part I find difficult to believe that it will operate reliably.  For a start, I have seen no detailed public description of TCP Prague, even though it has supposedly been in "open" development for so long.  My most recent information is that it's essentially a slightly modified DCTCP.

"  It would take time for endpoints to distinguish classic and L4S ECN
   marking.  An increase in queuing delay or in delay variation would be
   a tell-tale sign, but it is not yet clear where a line would be drawn
   between the two behaviours.  "

Internet history is littered with failed attempts at implementing delay-sensitive TCPs.  I can immediately think of several reasons why delay can and will vary for reasons other than the bottleneck not implementing an isolated queue  (just ask the BBR devs).  The mere presence of a wifi link on the path, even if it is never the bottleneck, would be a trivial and common example.

So please explain (or point to good documentation) how TCP Prague robustly avoids misbehaving in a standard ECN environment, as is presently deployed.


SCE explicitly does not rely on specific changes in behaviour by endpoints.  It just provides a conduit of information from the network to the receiver, in addition to standard ECN behaviour.  The receiver is free to ignore that information, without harming the network, and will naturally behave normally and safely when that information is absent.  We have a proof-of-concept implementation (a trivial mod of sch_codel and sch_fq_codel) which successfully passes this information across the Internet and works with (is transparently ignored by) existing endpoints and middleboxes.

In short, SCE is incrementally deployable by design.

The broader system of feedback and modified congestion control, which I call ELR (Explicit Load Regulation) as an umbrella term, offers benefits which, yes, have not yet been proved - but which are straightforward in concept and should be amenable to analysis.  It seems likely that some work from L4S can be used in this context.

 - Jonathan Morton


  reply	other threads:[~2019-03-19  7:10 UTC|newest]

Thread overview: 63+ 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   ` [Ecn-sane] " Dave Taht
     [not found]     ` <1E80578D-A589-4CA0-9015-B03B63042355@gmx.de>
2019-03-15 14:06       ` [Ecn-sane] [Bloat] " Dave Taht
2019-03-15 15:52         ` Sebastian Moeller
2019-03-15 17:01           ` 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  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 [this message]
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
     [not found]                     ` <5458c216-07b9-5b06-a381-326de49b53e0@bobbriscoe.net>
     [not found]                       ` <AC14ACBB-A7CC-40E0-882C-2519D05ADC05@akamai.com>
     [not found]                         ` <5C9296E1.4010703@erg.abdn.ac.uk>
     [not found]                           ` <F62C4839-0489-475F-AD8F-58913EEEEC0F@gmail.com>
     [not found]                             ` <FDA48F4C-415B-4B8E-9CC7-2AAAD4DC3BE8@cablelabs.com>
2019-03-20 22:12                               ` [Ecn-sane] [Bloat] [tsvwg] " 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                                         ` Mikael Abrahamsson
2019-03-21  8:31                                           ` Mikael Abrahamsson
2019-03-20 23:30                                       ` Sebastian Moeller
2019-03-21  0:15                                         ` Holland, Jake
2019-03-16 22:03                 ` [Ecn-sane] [Bloat] " 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       ` Jonathan Morton
2019-03-15 14:44         ` Sebastian Moeller
2019-03-15 15:49           ` Jonathan Morton
2019-03-15 21:34     ` Wesley Eddy

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=3C188730-DCD1-4359-AA19-F7526ECDF111@gmail.com \
    --to=chromatix99@gmail.com \
    --cc=bloat@lists.bufferbloat.net \
    --cc=dpreed@deepplum.com \
    --cc=ecn-sane@lists.bufferbloat.net \
    --cc=g.white@CableLabs.com \
    --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