From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sonic301-6.consmr.mail.bf2.yahoo.com (sonic301-6.consmr.mail.bf2.yahoo.com [74.6.129.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 0D66F3BA8E for ; Mon, 18 Mar 2019 18:04:00 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rogers.com; s=s2048; t=1552946640; bh=uU2OtXczDFjg3auQuT+CiAM+OrJPyt16o8lmBxiUCDY=; h=Reply-To:Subject:To:References:From:Date:In-Reply-To:From:Subject; b=KS79nZrB9utN6e+SHE/1d0/0hDExnjZD59SEMjvjmtuVCBtyApFtWUHIxNL/EtbH9WT2/Ohwy3uMPEDkAPEXg8VVDfHQ+IbUcpnJOyve7KmFA4J5a8Ukp3lMkWP6XU8QQw+0wvWw8JPXcIlYpLojeR2+S5ZDq9db1qGfbIp5fTE0yPSx1MssOJZJeet4sInTu4A/MLhgXsKdnyjCkKcvRJIEAl7ybTOFp7oX9UyGwvxKh3IdBCLs68o1dvzbKZTVozQBVqFOlsF5+LqNtPneZhiwcVa8BpFP8GAQ9uNG2CJRDICK1RVahmzcUV4K/9niEIqr4abiox450JC2Ent2UQ== X-YMail-OSG: 91OuVx0VM1l.sX_2Aw1.r4_sDWORWT8BL8N.Un8FdRTeVbINElD5jI1o6CeGaF1 Qr1F9zCWUwDmWT16AM5mgmkJLmZDVjszN87X0aV3zYYeZ2bVRH9ziCEIxqpeM.zWNsuByJ5mJ7r4 d.K_fh_zO7L7ogONoqNerrKIoU3is3IUlTJPKLWKijyfPCurpIZiaBDAcS3ym6NdtuFTWFGcI2w6 J.93R6xStFJJwT.F5dn.2u4Wl92LgkJhi4QKPYzKAc8JfR1PM0RbLyXTSwdSG6LYVYpEK6hyrIQ. P5G6lzKVcGHCdI7ZFtDfaJ8iZgPmUt3sNLQ2JbVmIfXc4RXSDNUriCgxg.gh8x3ZHVjr4nO7dBj6 Q2f5ZB6kbSQw.NxbyLw4GWx1_C2trXXkT9_y2.FvEiIqrS2OMjEo8cbwM9JiiWbP_PTKv8N4rSCS cCWyJhBBspeZKAz4zz497KE9ToVkioOrcIhyAMU9SeCSNh27U3kIAScfNm7uBrZmczjqCx6.inIq S6ckxm.Vmhig4IA7ik_S94EzbLaIPPZplBWbzt804Q1nyt6EdHdKSmc43IPfCQ7f7rEK835DwFA0 f_Hcmrg4rG8Vb6ClAJGakgMVNVC5vN9RRQul7pRcbHT5T6DK5qr81TkEkw74uSRD03gLiARxJIWC R0YEWBSsJBOpzTw0MBrpEJ2g_Nf9zxDYTcOEtuw1.3DJcgoIVunxRjAjHpAMPv_NmJrKUqanVusI 9SoneCjzHTaKueEb30YGp_BBB9kvKsT2I_e.HMscep_cG45bQ6SwGbgx0Eh0FIJIXCNlg7CgV04C vd_6YS36NlMaFBpe1tLSaS2SAW2Zgf4sH2YtbMDO5xbk2Am4HzM0boiF7GHIFXV.omGT1.hRk7NG kInpjEZQ1hNjM9vWOJ7pD7By7lojydCSCDH_I3JwCsYSXLAksngVuVfeWiJqVlaScueLiuLqHP3f 3nZnfPJBr3gdiioM.xmSAUHxUwVJ5tvEzKlexzAqWaCt_brAkvwbBUyRXSxoLZUcu5t8_G.oWGDq TG4aGdQEtjKfvDl.YoSfNulaMvf3alHPHMqFgHdD.Q0Mh80UCspnmrDPG52tew6mX Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.bf2.yahoo.com with HTTP; Mon, 18 Mar 2019 22:04:00 +0000 Received: from CPEbc4dfba21363-CMbc4dfba21360.cpe.net.cable.rogers.com (EHLO [192.168.0.15]) ([99.240.251.181]) by smtp424.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID e7378d78afc11be26ba1093e394c69a6; Mon, 18 Mar 2019 22:03:57 +0000 (UTC) Reply-To: davecb@spamcop.net To: bloat@lists.bufferbloat.net References: From: David Collier-Brown Message-ID: Date: Mon, 18 Mar 2019 18:03:56 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------20994F7694DFAB23DEB08351" Content-Language: en-US Subject: Re: [Bloat] My (controversial) position paper on TCP X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2019 22:04:01 -0000 This is a multi-part message in MIME format. --------------20994F7694DFAB23DEB08351 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hey Dave, are you available for consulting gigs in Canada? In my latest incarnation, I'm doing on-line auctions in < 120 milliseconds, with at least one round trip to ~10 bidders, and I suspect we never get out of slow start. I wonder if I can make a case that this is significant, and if you can suggest a consulting gig to fix it??? Centos on Intel, in this case. --dave On 2019-03-18 6:04 a.m., Dave Taht wrote: > I'm sure this would be controversial, and at the moment I'm focused on > testing some sce.h +fq_codel code for freebsd. I'll slam it into the > ecn-sane website at some point. > > ... > > TCP is done. It's baked. It's finished. There is very little left we > can do to improve it, and we should move on to improving new > transports such as QUIC which have option space left. [1] > > Ever since https://tools.ietf.org/html/rfc6013 failed in favor of tcp > fast open, I'd given up on tcp. It was a lousy rfc in that it didn't > make clear its best use case was in giving dns servers a safe and fast > way to use tcp, which would have helped reduce the amount of DDOS and > reflection attacks, speed things up, and so on. It wasn't until I had > a long discussion with paul vixie about this use case and worldwide > problem with dns that I understood it's intent to add a good stable > 3way handshake to dns was so good.... and by then it was too late. > > Instead, tcp fast open was standardized for a limited (IMHO) use case > of making web traffic better. Web traffic has a terrible interaction > with TCP, in that it tends to start up 6 or more simultaneous > connections and slam the link with stuff in slow start simultaneously. > Others standards that I opposed, like IW10 [2], also got adopted, and > we (as part of the cake project) tried to get an AQM (cobalt) that > responded faster to stuff in slow start. Which we succeeded at, and > that paper is progress, but it's still not good enough. > > It makes me really crazy that all the other TCP researchers in the > world tend to focus on improving TCP behavior in congestion avoidance > mode - because the statistics are easy to measure! - instead of > focusing on the 95% of flows that never manage to get out of slow > start. Yea, it's hard to look at slow start. That's why we've been > looking at it hard for 5+ years in the bufferbloat project - trying to > get linux, flent, irtt, to be able to look in detail at sub 4ms > intervals, among other things. > > There are so many other problems with TCP as a transport - it requires > a stateful firewall for ipv4 + nat, and more stuff than I have time to > go into today... > > One item off that long list: > > QUIC and Wireguard have a really nice 0 RTT reconnect over crypto > time. I like it a lot. I have not had time to poke much into the DOH > working group at the ietf, but my take on it was that we needed to > make dns better, not replace it. > > [1] Up until about 6 months ago, I really felt that we couldn't > improve tcp anymore. DCTCP was a dead end. However the SCE idea makes > it possible to have selectable behaviors on the receiver side - > notably, a low priority background transport application (for > backups/bittorrent) can merely overreact to SCE markings by sending > back ECE to the tcp sender thus getting them to back off faster and be > invisible to other applications. Or something more complicated (in > slow start phase) could be used. ACCUECN also seemed feasible. And > dctcp like approaches to another transport than tcp seemed very > feasible. > > But to me, the idea was that we'd improve low latency applications > such as gaming and videoconferencing and VR/AR with SCE, not "fix" > tcp, overall. Goal in life was to have 0 latency for all flows - if it > cost a little bandwidth, fine - 0 latency. The world is evolving to > "enough" bandwidth for everything, but still has too much latency. The > whole l4s thing conflating the benefits low latency with an > ecn-enabled tcp has makes me crazy because it isn't true, as loss is > just fine on most paths - lordy I don't want to go into that here, > today. loss hurts gaming and videoconferencing more. > > Another ietf idea that makes me crazy is the motto of "no host > changes" in homenet, and "dumb endpoints" - when we live in an age > where we have quad cores and AI coprocessors in everybody's hands. > > The whole QUIC experiment shows what can be done when you have smart > endpoints, along with a network that is as dumb as possible, but no > dumber. > > [2] https://tools.ietf.org/html/draft-gettys-iw10-considered-harmful-00 > > I would prefer folk wrote a position paper for ecn-sane rather than > endlessly discuss this over email. that said, I needed to get this out > of my system. > -- David Collier-Brown, | Always do right. This will gratify System Programmer and Author | some people and astonish the rest davecb@spamcop.net | -- Mark Twain --------------20994F7694DFAB23DEB08351 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hey Dave, are you available for consulting gigs in Canada?

In my latest incarnation, I'm doing on-line auctions in < 120 milliseconds, with at least one round trip to ~10 bidders, and I suspect we never get out of slow start.

I wonder if I can make a case that this is significant, and if you can suggest a consulting gig to fix it??? Centos on Intel, in this case. 

--dave
On 2019-03-18 6:04 a.m., Dave Taht wrote:
I'm sure this would be controversial, and at the moment I'm focused on
testing some sce.h +fq_codel code for freebsd. I'll slam it into the
ecn-sane website at some point.

...

TCP is done. It's baked. It's finished. There is very little left we
can do to improve it, and we should move on to improving new
transports such as QUIC which have option space left. [1]

Ever since https://tools.ietf.org/html/rfc6013 failed in favor of tcp
fast open, I'd given up on tcp. It was a lousy rfc in that it didn't
make clear its best use case was in giving dns servers a safe and fast
way to use tcp, which would have helped reduce the amount of DDOS and
reflection attacks, speed things up, and so on. It wasn't until I had
a long discussion with paul vixie about this use case and worldwide
problem with dns that I understood it's intent to add a good stable
3way handshake to dns was so good.... and by then it was too late.

Instead, tcp fast open was standardized for a limited (IMHO) use case
of making web traffic better. Web traffic has a terrible interaction
with TCP, in that it tends to start up 6 or more simultaneous
connections and slam the link with stuff in slow start simultaneously.
Others standards that I opposed, like IW10 [2], also got adopted, and
we (as part of the cake project) tried to get an AQM (cobalt) that
responded faster to stuff in slow start. Which we succeeded at, and
that paper is progress, but it's still not good enough.

It makes me really crazy that all the other TCP researchers in the
world tend to focus on improving TCP behavior in congestion avoidance
mode - because the statistics are easy to measure! - instead of
focusing on the 95% of flows that never manage to get out of slow
start. Yea, it's hard to look at slow start. That's why we've been
looking at it hard for 5+ years in the bufferbloat project - trying to
get linux, flent, irtt, to be able to look in detail at sub 4ms
intervals, among other things.

There are so many other problems with TCP as a transport - it requires
a stateful firewall for ipv4 + nat, and more stuff than I have time to
go into today...

One item off that long list:

QUIC and Wireguard have a really nice 0 RTT reconnect over crypto
time. I like it a lot. I have not had time to poke much into the DOH
working group at the ietf, but my take on it was that we needed to
make dns better, not replace it.

[1] Up until about 6 months ago, I really felt that we couldn't
improve tcp anymore. DCTCP was a dead end. However the SCE idea makes
it possible to have selectable behaviors on the receiver side -
notably, a low priority background transport application (for
backups/bittorrent) can merely overreact to SCE markings by sending
back ECE to the tcp sender thus getting them to back off faster and be
invisible to other applications. Or something more complicated (in
slow start phase) could be used. ACCUECN also seemed feasible. And
dctcp like approaches to another transport than tcp seemed very
feasible.

But to me, the idea was that we'd improve low latency applications
such as gaming and videoconferencing and VR/AR with SCE, not "fix"
tcp, overall. Goal in life was to have 0 latency for all flows - if it
cost a little bandwidth, fine - 0 latency. The world is evolving to
"enough" bandwidth for everything, but still has too much latency. The
whole l4s thing conflating the benefits low latency with an
ecn-enabled tcp has makes me crazy because it isn't true, as loss is
just fine on most paths - lordy I don't want to go into that here,
today. loss hurts gaming and videoconferencing more.

Another ietf idea that makes me crazy is the motto of "no host
changes" in homenet, and "dumb endpoints" - when we live in an age
where we have quad cores and AI coprocessors in everybody's hands.

The whole QUIC experiment shows what can be done when you have smart
endpoints, along with a network that is as dumb as possible, but no
dumber.

[2] https://tools.ietf.org/html/draft-gettys-iw10-considered-harmful-00

I would prefer folk wrote a position paper for ecn-sane rather than
endlessly discuss this over email. that said, I needed to get this out
of my system.


-- 
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
davecb@spamcop.net           |                      -- Mark Twain
--------------20994F7694DFAB23DEB08351--