From: Jonathan Morton <chromatix99@gmail.com>
To: Carsten Bormann <cabo@tzi.org>
Cc: Sebastian Moeller <moeller0@gmx.de>,
ECN-Sane <ecn-sane@lists.bufferbloat.net>,
bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Ecn-sane] [Bloat] sce materials from ietf
Date: Sun, 1 Dec 2019 00:23:05 +0200 [thread overview]
Message-ID: <8C5FD2CE-D24F-4998-A636-8F85279C67BA@gmail.com> (raw)
In-Reply-To: <CA4B0BC9-D9B4-4AC4-8E98-D8C2EB52C37E@tzi.org>
> On 1 Dec, 2019, at 12:17 am, Carsten Bormann <cabo@tzi.org> wrote:
>
>> There are unfortunate problems with introducing new TCP options, in that some overzealous firewalls block traffic which uses them. This would be a deployment hazard for SCE, which merely using a spare header flag avoids. So instead we are still planning to use the spare bit - which happens to be one that AccECN also uses, but AccECN negotiates in such a way that SCE can safely use it even with an AccECN capable partner.
>
> This got me curious: Do you have any evidence that firewalls are friendlier to new flags than to new options?
Mirja Kuhlewind said as much during the TCPM session we attended, and she ought to know. There appear to have been several studies performed on this subject; reserved TCP flags tend to get ignored pretty well, but unknown TCP options tend to get either stripped or blocked.
This influenced the design of AccECN as well; in an early version it would have used only a TCP option and left the TCP flags alone. When it was found that firewalls would often interfere with this, the three-bit field in the TCP flags area was cooked up.
- Jonathan Morton
next prev parent reply other threads:[~2019-11-30 22:23 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-29 20:08 [Ecn-sane] " Dave Taht
2019-11-29 21:20 ` [Ecn-sane] [Bloat] " Jonathan Morton
2019-11-29 23:10 ` alex.burr
2019-11-30 1:39 ` Jonathan Morton
2019-11-30 7:27 ` Sebastian Moeller
2019-11-30 14:32 ` Jonathan Morton
2019-11-30 15:42 ` Sebastian Moeller
2019-11-30 17:11 ` Jonathan Morton
2019-12-02 5:38 ` Dave Taht
2019-12-02 7:54 ` Sebastian Moeller
2019-12-02 9:57 ` Pete Heist
2019-11-30 22:17 ` Carsten Bormann
2019-11-30 22:23 ` Jonathan Morton [this message]
2019-12-01 16:35 ` Sebastian Moeller
2019-12-01 16:54 ` Jonathan Morton
2019-12-01 19:03 ` Sebastian Moeller
2019-12-01 19:27 ` Jonathan Morton
2019-12-01 19:32 ` Sebastian Moeller
2019-12-01 20:30 ` Jonathan Morton
2019-12-01 17:30 ` Rodney W. Grimes
2019-12-01 19:17 ` Sebastian Moeller
2019-12-02 5:10 ` Dave Taht
2019-12-02 7:18 ` Sebastian Moeller
2019-11-29 22:55 ` [Ecn-sane] " Rodney W. Grimes
2019-11-29 22:58 ` Rodney W. Grimes
2019-11-30 2:37 ` Dave Taht
2019-11-30 3:10 ` Rodney W. Grimes
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=8C5FD2CE-D24F-4998-A636-8F85279C67BA@gmail.com \
--to=chromatix99@gmail.com \
--cc=bloat@lists.bufferbloat.net \
--cc=cabo@tzi.org \
--cc=ecn-sane@lists.bufferbloat.net \
--cc=moeller0@gmx.de \
/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