From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 5F5183B29E for ; Sun, 17 Mar 2019 06:23:44 -0400 (EDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [IPv6:2001:638:708:30c8:406a:91ff:fe74:f2b7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id x2HANU3M023095; Sun, 17 Mar 2019 11:23:35 +0100 (CET) Received: from client-0247.vpn.uni-bremen.de (client-0247.vpn.uni-bremen.de [134.102.107.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 44Mb4f35NQz1Bp8; Sun, 17 Mar 2019 11:23:30 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: Date: Sun, 17 Mar 2019 11:23:29 +0100 Cc: Greg White , Ingemar Johansson S , "bloat@lists.bufferbloat.net" X-Mao-Original-Outgoing-Id: 574511006.316386-b01bc263cac0358206a216daf8ac728f Content-Transfer-Encoding: quoted-printable Message-Id: <94B04C6B-5997-4971-9698-57BEA3AE5C0E@tzi.org> References: To: Sebastian Moeller X-Mailer: Apple Mail (2.3445.9.1) Subject: Re: [Bloat] Packet reordering and RACK (was The "Some Congestion Experienced" ECN codepoint) 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: Sun, 17 Mar 2019 10:23:44 -0000 On Mar 14, 2019, at 22:43, Sebastian Moeller wrote: >=20 > if a specific link technology is prone to introduce reordering due to = retransmit it might as well try to clean up after itself The end-to-end argument applies: Ultimately, there needs to be = resequencing at the end anyway, so any reordering in the network would = be a performance optimization. It turns out that keeping packets lying = around in some buffer somewhere in the network just to do resequencing = before they exit an L2 domain (or a tunnel) is a pessimization, not an = optimization. For three decades now, we have acted as if there is no cost for in-order = delivery from L2 =E2=80=94 not because that is true, but because = deployed transport protocol implementations were built and tested with = simple links that don=E2=80=99t reorder. Techniques for ECMP = (equal-cost multi-path) have been developed that appease that illusion, = but they actually also are pessimizations at least in some cases. The question at hand is whether we can make the move back to end-to-end = resequencing techniques that work well, at least within some limits that = we still have to find. That probably requires some evolution at the = end-to-end transport implementation layer. We are in a better position = to make that happen than we have been for a long time. Gr=C3=BC=C3=9Fe, Carsten