netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).