From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp76.iad3a.emailsrvr.com (smtp76.iad3a.emailsrvr.com [173.203.187.76]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 2F65A3B29D for ; Sun, 12 Apr 2020 12:15:31 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=g001.emailsrvr.com; s=20190322-9u7zjiwi; t=1586708130; bh=nHmOTqqB2M2p2xpMbl0oANIjdDrSWcABF+I0wI1Roh4=; h=Date:Subject:From:To:From; b=Yfzk7dUt4XbvThJeFGRW3E+HIoEtMiifIL9XhkYVjeY5++pv3iqN1TAjc4vn6nB2s poZXzocSgkF4/mL7Ps75k0GPaUCAoqLIVyExFJIlFzwKMj/v5dwOZjAXGQx1zEk8rO LTmRaUo9wZatLKNjoymdyytnpgJl5/oWC/qOewqw= Received: from app5.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp34.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id D070C22264; Sun, 12 Apr 2020 12:15:30 -0400 (EDT) X-Sender-Id: dpreed@deepplum.com Received: from app5.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.7.12); Sun, 12 Apr 2020 12:15:30 -0400 Received: from deepplum.com (localhost.localdomain [127.0.0.1]) by app5.wa-webapps.iad3a (Postfix) with ESMTP id B81C1613FF; Sun, 12 Apr 2020 12:15:30 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@deepplum.com, from: dpreed@deepplum.com) with HTTP; Sun, 12 Apr 2020 12:15:30 -0400 (EDT) X-Auth-ID: dpreed@deepplum.com Date: Sun, 12 Apr 2020 12:15:30 -0400 (EDT) From: "David P. Reed" To: "Dave Taht" Cc: "cerowrt-devel" MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-Type: plain In-Reply-To: References: Message-ID: <1586708130.751530183@apps.rackspace.com> X-Mailer: webmail/17.3.5-RC X-Classification-ID: b2b25a84-867d-4f10-9164-1b10d7602df5-1-1 Subject: Re: [Cerowrt-devel] 800gige 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: Sun, 12 Apr 2020 16:15:31 -0000 Sadly, out-of-order delivery tolerance was a "requirement" when we designed= TCP originally. There was a big motivation: spreading traffic across a var= iety of roughly equivalent paths, when you look at the center of the networ= k activity (not the stupid image called "backbone" the forces you to think = it is just one pipe in the middle).=0AInstead a bunch of bell-head, circuit= -oriented thought was engineered into TCP's later assumptions (though not U= DP, thank the lord). And I mean to be insulting there.=0A=0AIt continues to= appall me how much the post-1990 TCP tinkerers have assumed "almost perfec= tly in-order" delivery of packets that are in transit in the network betwee= n endpoints, and how much they screw up when that isn't true.=0A=0AAlmost e= very paper in the literature (and RFC's) makes the assumption. =0A=0ABut he= re's the point. With a little careful thought, it is unnecessary to make th= is assumption in almost all cases. For example: you can get the effect of S= ACK without having to assume that delivery is almost in-order. And the resu= t will be a protocol that works better for out-of-order delivery, and also = have much better performance wnen in-order delivery happens to occur. (and = that's not even taking advantage of erasure coding like the invention calle= d "Digital Fountains", which is also an approach for out-of-order delivery = in TCP).=0A=0AThis is another example of the failure to adhere to the end-t= o-end argument. You don't need to put "near-in-order-delivery" as a functio= n into the network to get the result you want (congestion control, efficien= t error-tolerance). So don't put that requirement on the network. Let it ch= oose a different route for every packet from A to B.=0A=0A=0A=0AOn Saturday= , April 11, 2020 7:08pm, "Dave Taht" said:=0A=0A> The= way I've basically looked at things since 25Gbit ethernet was that=0A> imp= rovements in single stream throughput were dead. I see a lot of=0A> work on= out of order delivery tolerance as an outgrowth of that,=0A> but... am I w= rong?=0A> =0A> https://ethernettechnologyconsortium.org/wp-content/uploads/= 2020/03/800G-Specification_r1.0.pdf=0A> =0A> --=0A> Make Music, Not War=0A>= =0A> Dave T=C3=A4ht=0A> CTO, TekLibre, LLC=0A> http://www.teklibre.com=0A>= Tel: 1-831-435-0729=0A> _______________________________________________=0A= > Cerowrt-devel mailing list=0A> Cerowrt-devel@lists.bufferbloat.net=0A> ht= tps://lists.bufferbloat.net/listinfo/cerowrt-devel=0A> =0A