From: Dave Taht <dave.taht@gmail.com>
To: Jonathan Morton <chromatix99@gmail.com>
Cc: ECN-Sane <ecn-sane@lists.bufferbloat.net>,
Daniel Havey <dhavey@gmail.com>
Subject: Re: [Ecn-sane] simpler solution for ecn + cwnd < 2 than sub-packet windows
Date: Tue, 30 Jul 2019 11:23:24 -0700 [thread overview]
Message-ID: <CAA93jw429LL5SxOo7dYTfMcMExbBcAtpp-VaViS6k5wmqD7JMA@mail.gmail.com> (raw)
In-Reply-To: <CAJq5cE2y2DtiH_58U6+KKgz8cWFtvWWtgW=-s2g_ZDtVFihcDg@mail.gmail.com>
On Mon, Jul 29, 2019 at 2:22 AM Jonathan Morton <chromatix99@gmail.com> wrote:
>
> No, the single easiest solution is to reduce the pacing scale factors. The packets are still full size, but appear less often, potentially less than one per RTT.
Pacing is GREAT, but unlikely to take over the universe all that
rapidly. For anything else with ecn on, a fallback to signalling it's
ok to drop me under extreme congestion seems helpful, and the further
fallbacks that regular tcp has, has have proved sufficient for the
internet.
If we successfully get away from ect1 as an identifier and instead as
a robust set of congestion indicators, senders falling back to 00 is a
possibility.
And it's simple to implement. I note that it might not just be cwnd 2
but at solid levels of SCE or CE marking.
I also like dynamically reducing the MSS to keep the signal strength
up for 1 per RTT for as long as possible.
I've also suggested on multiple occasions that webrtc use ECN for
iframes, but turn it off for deltas.
I'm not saying I don't like subpacket windows!
But not every packet's sacred, and my position paper laid out some
nuances that I need to revise some in light of the enormous
progress made on SCE so far. I rather like the SCE-enabled scavanging
transport idea, as it's kind of similar to the extreme but useful
response to ecn we put into mosh, where we drop the frame rate from
its max of 60 to 1 or 2, in response to CE. Mosh is an example of an
interactive application where going a step further to protect a packet
really helps, but dropping the rate by a large amount, doesn't hurt.
(much)
https://tools.ietf.org/html/rfc8622 lays out two conflicting goals for
a scavenging transport - one that must be low priority and another
that must be capable of being silenced for long periods of time. LE +
SCE enablement and a fallback to being 00 and thus lossy is a possible
way to achieve those goals based on the application's actual intent.
The ledbat++ preso in iccrg is also worth watching, btw, lthough I
fear they haven't actually read
https://perso.telecom-paristech.fr/drossi/paper/rossi14comnet-b.pdf
--
Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740
prev parent reply other threads:[~2019-07-30 18:23 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-29 4:50 Dave Taht
2019-07-29 9:22 ` Jonathan Morton
2019-07-30 18:23 ` Dave Taht [this message]
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=CAA93jw429LL5SxOo7dYTfMcMExbBcAtpp-VaViS6k5wmqD7JMA@mail.gmail.com \
--to=dave.taht@gmail.com \
--cc=chromatix99@gmail.com \
--cc=dhavey@gmail.com \
--cc=ecn-sane@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