From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x843.google.com (mail-qt1-x843.google.com [IPv6:2607:f8b0:4864:20::843]) (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 521B63B2A4; Mon, 18 Mar 2019 06:05:10 -0400 (EDT) Received: by mail-qt1-x843.google.com with SMTP id h39so17177126qte.2; Mon, 18 Mar 2019 03:05:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=Rc+lT+OLzQQS7WqZY6wSGgjiBd+mcl2jkFbEgu73Y1M=; b=Xfu2Z0OQelOi9LRBXd/Yx+sKX6K/jdkKcMiTtdnH0Gde8d+EDgdxh2ymBk7UM6NxU1 Idcbmlfvu8/htg7hyj7YVm/VL9MOp2o54AzWxkKQi9gwRYsUTcxT9oaWP7MUIL+7WOkq NfQ+Ovl6e5dbfc1JdR+wI+WqIhJBPLsZ08HfyyA7m2Jj13sdVgp49Ic2F3X9x80RqyEn Y7TQP7ul9TZQz4MwBARkUM5+9qx4JBlvckm3+xOMNWpZ81FBNHLm8pOKWNxAiisU4y4b bIqNNWOMZVttDh0sZmqf71zhV2qKm7THcxiyVPURKlTiVlzhIKazuthB04p7Vymti84v GoLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=Rc+lT+OLzQQS7WqZY6wSGgjiBd+mcl2jkFbEgu73Y1M=; b=os/HWZeLR0beFxEzOhGXm5A2p3RZasBle6n7n03w38+sI5sSDX/nMWm6XLNlAPMQmP BZBJKy4G5Ty7ARxCoFp61ZRAxyu3VkFHKjvGqOgA6LTxEa2AqXF5pD6KfoSi6kVvHpK0 4rstC+zjhAv9wtlGSjbMwi6JtwQ/2rCiI4KxvcvknbGgvYSZ97PMcg5Y11bc1iLZsgnZ /mGw2jyfZZAc40Dwrr/LlRuGICdAjQyT+9uxLkwC4GtfW7SJsGq5BQOgcTmeQ3svd5/s 5yn0skG5TdFoXNnTynmiKzpNxP8A1E9v6hSgRpcU7NI5/RWaFV33gj1U9pnJyKHyvohI Ynmg== X-Gm-Message-State: APjAAAWEWSoH/V21KG6VvIkBirWZG8Jr/+gyb85aA0I3o6GdjCt05blC XPNZmDXtEXJbJ9N3ncGmsvtjL3zw97YlZ/SwxzDsL0ou X-Google-Smtp-Source: APXvYqwI94lxlRpz4dWJ1aQTHmn65F0Ykaw54r/HeOoWM/lVQEnleHbGTPhNxar60xEPTj0gcw8OKe949u82Liu1tuA= X-Received: by 2002:ac8:30e8:: with SMTP id w37mr7801522qta.136.1552903509337; Mon, 18 Mar 2019 03:05:09 -0700 (PDT) MIME-Version: 1.0 From: Dave Taht Date: Mon, 18 Mar 2019 03:04:57 -0700 Message-ID: To: ecn-sane@lists.bufferbloat.net, bloat , Cake List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: [Cake] My (controversial) position paper on TCP X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2019 10:05:10 -0000 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. --=20 Dave T=C3=A4ht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740