From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (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 A22613CB35 for ; Sat, 23 Mar 2019 02:15:45 -0400 (EDT) Received: by mail-qt1-x830.google.com with SMTP id w5so4972202qtb.11 for ; Fri, 22 Mar 2019 23:15:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=8v1z4vh6SRkgoda0VEs6agoegRP4eMTqmqxZqyDwYUc=; b=l9YmIKxquSMK6MhTHqmJ285QtFOH6Fz9C7EdsEU00eZR75LWCiboMk3Oi/Jfsy8vfh mPI3tfJi1hCnYE0Lr1AJKxWkHI5dFDeJUtXVpVb22WL+NyzezQ8ghIDRmsD+rATE41Qf X8dNL2QIcXeXfr7EE9EByFCzcj72T+YUMDgqKph1TGne7tLFKqc/SG/3IdbE/WL6xVLY 77CNqR6C/5xlK63/kGi+0ydfTI+DS+EUBWDePZ1t/eeVZnzqJxI+caOeY3x53qU7pHdF iyXSgIDdqJxjGpFs5TBqoQE3NQoQNJ6epWwm3leAaPM8ahOR3V4aUhwqBWtHOyCVSTSY Vj1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=8v1z4vh6SRkgoda0VEs6agoegRP4eMTqmqxZqyDwYUc=; b=UmYopET79IFCj+BRxD3NrCG1AnYD7JO5Q+kGlv6EJ8QZsIBFFbfmfLHnkEv+CL+snH vxlWlIiKwKNVsvtxqmb6XIXHHU4nxxZqAjuEkoTxmqm/WvKilNFK1hBOQJ1oRG9t/MOv wK6huEhC2BJr7qaAwm2GyqW4g5RPJAbXK94T/l+znQxmeyD+RC7kijOxLkBxIctvrnkx faJ6MRwd3BsesrAOzAIhX2yaQSmYcW+BarH9zVMma6KIFzuBji0px9IXEHQ3kbc1xS8R kSo45Ph1omtIR6txAQZHTEMPFRM3vGPdofcShbGa629uHY1qWGAWaGZl3Vg9FLYnNz+J 46jQ== X-Gm-Message-State: APjAAAUu7blLbxui2l4mt487eUHCo48P49rBtzSpymhLEdFS/KBUADDW 6U1nvkDfStqtlIu3Za8qtv8TvZIrxt/WS1IHP5cJwsfC9i0GEw== X-Google-Smtp-Source: APXvYqyBpoXiKMwN9ivDzk3txSCcvzb+rFoAX/k/V5F67JEHp26YTMPP1360s9t2YcR1XGCfnhroR1nYCpTo8hnT+XQ= X-Received: by 2002:ac8:2207:: with SMTP id o7mr11546472qto.376.1553321744952; Fri, 22 Mar 2019 23:15:44 -0700 (PDT) MIME-Version: 1.0 References: <8bff80d6-9b5f-6963-1bc5-45bfab636008@lackof.org> In-Reply-To: <8bff80d6-9b5f-6963-1bc5-45bfab636008@lackof.org> From: Dave Taht Date: Sat, 23 Mar 2019 07:15:33 +0100 Message-ID: To: Matt Taggart Cc: cerowrt-devel Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Cerowrt-devel] Will transport innovation collapse the Internet? X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2019 06:15:45 -0000 On Sat, Mar 23, 2019 at 1:31 AM Matt Taggart wrote: > > This is from Jan 12th but I hadn't seen it yet. > > https://huitema.wordpress.com/2019/01/12/will-transport-innovation-collap= se-the-internet/ I am awaiting moderation on this comment: While I agree with your thesis, about the problem! I am very bothered by your descriptions of the timelines and who were involved. Other processes are required long before something hits the ietf and recent attempts to file the serial numbers off in favor of corporate =E2=80=9Cinnovation=E2=80=9D rather bug me, so: 1) =E2=80=9CMore recent algorithms were developed in the IETF AQM Working Group to address the =E2=80=9Cbuffer bloat=E2=80=9D problem, such as FQ-COD= EL or PIE. =E2=80=9D fq_codel sprang from an outside the ietf effort (bufferbloat.net) founded by myself and jim gettys in 2011. In may of 2012 (after many other innovations in linux such as BQL (which made FQ and AQM technology possible), multiple other fixes in the stack, the publication of Van Jacobson=E2=80=99s and Kathie nichols=E2=80=99s paper on= codel (which we turned from ns2 to linux in a week, and arrived in linux mainline the week later)=E2=80=A6 and two weeks later .- fq_codel incorpora= ted the best of all our research. It took 6 hours to write, and while there have been many minor tweaks along the way, it then took 6 years to standardize in the IETF while achieving a near total deployment in linux today, and is now in freebsd. The ietf AQM working group was founded only because of and after VJ and Kathie=E2=80=99s breakthrough AQM design. It was a hard fight to even g= et fair queuing as part of the charter. 2) QUIC=E2=80=99s real history started with a renegade engineer (Jim Roskin= d, father of QUIC) that gathered a small team inside google to re-examine tcp in the context of web traffic around 2011 =E2=80=93 3 years before you claim it happened. See the commit logs. They re-evaluated 30 years of discarded tcp ideas, and retried them, much in the manner of how edison would try 3000 ideas to get one. Month in month out, they built release after release, wrote the code, deployed it, made changes to the code and protocol on a monthly basis. They faced enormous barriers by folk that thought we should just fix tcp, or laughed at each new idea and said that couldn=E2=80=99t (or shouldn=E2=80=99t) be done. They just went ahead and did it. Every time they made a =E2=80=9Cbreaking change=E2=80=9D in the protocol th= ey bumped the version number. Sometimes it was crypto, sometimes frames, sometimes congestion control, etc. It went through *20* *deployed* revisions before it made the ietf. Looking at the wire spec https://docs.google.com/document/d/1WJvyZflAO2pq77yOLbp9NsGjC1CHetAXV8I0fQe= -B_U/edit You can see the long list of recent versions: Q009: added priority as the first 4 bytes on spdy streams. Q010: renumber the various frame types Q011: shrunk the fnv128 hash on NULL encrypted packets from 16 bytes to 12 bytes. Q012: optimize the ack frame format to reduce the size and better handle ranges of nacks, which should make truncated acks virtually impossible. Also adding an explicit flag for truncated acks and moving the ack outside of the connection close frame. Q013: Compressed headers for *all* data streams are serialized into a reserved stream. This ensures serialized handling of headers, independent of stream cancellation notification. Q014: Added WINDOW_UPDATE and BLOCKED frames, no behavioral change. Q015: Removes the accumulated_number_of_lost_packets field from the TCP and inter arrival congestion feedback frames and adds an explicit list of recovered packets to the ack frame. Q016: Breaks out the sent_info field from the ACK frame into a new STOP_WAITING frame. Changed GUID to Connection ID Q017: Adds stream level flow control Q018: Added a PING frame Q019: Adds session/connection level flow control Q020: Allow endpoints to set different stream/session flow control windows Q021: Crypto and headers streams are flow controlled (at stream level) Q023: Ack frames include packet timestamps Q024: HTTP/2-style header compression Q025: HTTP/2-style header keys. Removal of error_details from the RST_STREAM frame. Q026: Token binding, adds expected leaf cert (XLCT) tag to client hello Q027: Adds a nonce to the server hello Q029: Server and client honor QUIC_STREAM_NO_ERROR on early response Q030: Add server side support of certificate transparency. Q031: Adds a SHA256 hash of the serialized client hello messages to crypto proof. Q032: FEC related fields are removed from wire format. Q033: Adds an optional diversification nonce to packet headers, and eliminates the 2 byte and 4 byte connection ID length public flags. Q034: Removes entropy and private flags and changes the ack frame from nack ranges to ack ranges and removes truncated acks. Q035: Allows each endpoint to independently set maximum number of supported incoming streams using the MIDS (=E2=80=9CMaximum Incoming Dynami= c Streams=E2=80=9D) tag instead of the older MSPC (=E2=80=9CMaximum Streams P= er Connection=E2=80=9D) tag. Q036: Adds support for inducing head-of-line blocking between streams via the new FHOL tag in the handshake. Jim Roskind is a hero. =E2=80=A6 Your article also conflates QUIC with BBR. BBR is a congestion control algorithm. QUIC is a protocol that can use any congestion control algorithm. > -- > Matt Taggart > matt@lackof.org > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel --=20 Dave T=C3=A4ht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740