From: Rick Jones <rick.jones2@hpe.com>
To: Tom Herbert <tom@herbertland.com>
Cc: Richard Weinberger <richard@nod.at>,
David Miller <davem@davemloft.net>,
Linux Kernel Network Developers <netdev@vger.kernel.org>,
Kernel Team <kernel-team@fb.com>
Subject: Re: [PATCH net-next 0/8] tou: Transports over UDP - part I
Date: Fri, 24 Jun 2016 15:06:49 -0700 [thread overview]
Message-ID: <576DAEF9.8080501@hpe.com> (raw)
In-Reply-To: <CALx6S34Vu_xG7jjTSdFXdbkJOfKt=639ji5DX4gOjObi8Nf+7A@mail.gmail.com>
On 06/24/2016 02:46 PM, Tom Herbert wrote:
> On Fri, Jun 24, 2016 at 2:36 PM, Rick Jones <rick.jones2@hpe.com> wrote:
>> How would you define "severely?" Has it actually been more severe than for
>> say ECN? Or it was for say SACK or PAWS?
>>
> ECN is probably even a bigger disappointment in terms of seeing
> deployment :-( From http://ecn.ethz.ch/ecn-pam15.pdf:
>
> "Even though ECN was standardized in 2001, and it is widely
> implemented in end-systems, it is barely deployed. This is due to a
> history of problems with severely broken middleboxes shortly after
> standardization, which led to connectivity failure and guidance to
> leave ECN disabled."
>
> SACK and PAWS seemed to have faired a little better I believe.
The conclusion of that (rather interesting) paper reads:
"Our analysis therefore indicates that enabling ECN by default would
lead to connections to about five websites per thousand to suffer
additional setup latency with RFC 3168 fallback. This represents an
order of magnitude fewer than the about forty per thousand which
experience transient or permanent connection failure due to other
operational issues"
Doesn't that then suggest that not enabling ECN is basically a matter of
FUD more than remaining assumed broken middleboxes?
My main point is that in the past at least, trouble with broken
middleboxes didn't lead us to start wrapping all our TCP/transport
traffic in UDP to try to hide it from them. We've managed to get SACK
and PAWS universal without having to resort to that, and it would seem
we could get ECN universal if we could overcome our FUD. Why would TFO
for instance be any different?
There was an equally interesting second paragraph in the conclusion:
"As not all websites are equally popular, failures on five per thousand
websites does not by any means imply that five per thousand connection
attempts will fail. While estimation of connection attempt rate by rank
is out of scope of this work, we note that the highest ranked website
exhibiting stable connection failure has rank 596, and only 13 such
sites appear in the top 5000"
rick jones
next prev parent reply other threads:[~2016-06-24 22:06 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-16 17:51 [PATCH net-next 0/8] tou: Transports over UDP - part I Tom Herbert
2016-06-16 17:51 ` [PATCH net-next 1/8] net: Change SKB_GSO_DODGY to be a tx_flag Tom Herbert
2016-06-16 18:58 ` Alexander Duyck
2016-06-16 20:18 ` Tom Herbert
2016-06-16 20:33 ` Alexander Duyck
2016-06-17 22:33 ` Tom Herbert
2016-06-16 17:51 ` [PATCH net-next 2/8] fou: Change ip_tunnel_encap to take net argument Tom Herbert
2016-06-16 17:51 ` [PATCH net-next 3/8] tou: Base infrastructure for Transport over UDP Tom Herbert
2016-06-16 17:51 ` [PATCH net-next 4/8] ipv4: Support TOU Tom Herbert
2016-06-16 17:51 ` [PATCH net-next 5/8] tcp: Support for TOU Tom Herbert
2016-06-16 17:52 ` [PATCH net-next 6/8] ipv6: Support TOU Tom Herbert
2016-06-16 17:52 ` [PATCH net-next 7/8] tcp6: Support for TOU Tom Herbert
2016-06-16 17:52 ` [PATCH net-next 8/8] tou: Support for GSO Tom Herbert
2016-06-16 18:10 ` [PATCH net-next 0/8] tou: Transports over UDP - part I Rick Jones
2016-06-16 23:15 ` Hannes Frederic Sowa
2016-06-17 16:51 ` Tom Herbert
2016-06-21 16:56 ` Hannes Frederic Sowa
2016-06-18 3:09 ` David Miller
2016-06-18 3:52 ` Tom Herbert
2016-06-19 20:15 ` Hajime Tazaki
2016-06-20 3:07 ` David Miller
2016-06-20 15:13 ` Tom Herbert
2016-06-21 8:29 ` David Miller
2016-06-22 3:42 ` Jerry Chu
2016-06-22 4:06 ` David Ahern
2016-06-22 19:24 ` David Miller
2016-06-22 17:40 ` Tom Herbert
2016-06-22 19:23 ` David Miller
2016-06-25 15:56 ` Tom Herbert
2016-06-21 17:11 ` Hannes Frederic Sowa
2016-06-21 17:23 ` Tom Herbert
2016-06-22 22:15 ` Richard Weinberger
2016-06-22 22:56 ` Tom Herbert
2016-06-23 7:40 ` David Miller
2016-06-23 7:50 ` Richard Weinberger
2016-06-24 21:12 ` Tom Herbert
2016-06-24 21:36 ` Rick Jones
2016-06-24 21:46 ` Tom Herbert
2016-06-24 22:06 ` Rick Jones [this message]
2016-06-24 23:43 ` Tom Herbert
2016-06-25 0:01 ` Rick Jones
2016-06-25 16:22 ` Tom Herbert
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=576DAEF9.8080501@hpe.com \
--to=rick.jones2@hpe.com \
--cc=davem@davemloft.net \
--cc=kernel-team@fb.com \
--cc=netdev@vger.kernel.org \
--cc=richard@nod.at \
--cc=tom@herbertland.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;
as well as URLs for NNTP newsgroup(s).