From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.lang.hm (unknown [66.167.227.145]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 932E63B2A4 for ; Thu, 14 Mar 2019 18:06:19 -0400 (EDT) Received: from dlang-laptop.LAN (dlang-laptop.LAN [10.2.0.162]) by mail.lang.hm (Postfix) with ESMTP id AF8835E334; Thu, 14 Mar 2019 15:05:50 -0700 (PDT) Date: Thu, 14 Mar 2019 15:05:50 -0700 (PDT) From: David Lang X-X-Sender: dlang@dlang-laptop To: Sebastian Moeller cc: Greg White , Ingemar Johansson S , "bloat@lists.bufferbloat.net" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21.1 (DEB 209 2017-03-23) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed 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: Thu, 14 Mar 2019 22:06:19 -0000 On Thu, 14 Mar 2019, Sebastian Moeller wrote: > As I tried to convey, if the local ARQ is considerably faster than the > bottleneck link for each flow, local re-ordering comes at a considerably lower > intra-flow latency cost than re-ordering past the bottleneck link. And one > could argue, if a specific link technology is prone to introduce reordering > due to retransmit it might as well try to clean up after itself... As soon as you introduce parallelism (either multiple cores working on the traffic or multiple paths, including different frequencies in the medium) then strict ordering starts becomingexpensive > To my knowledge most traffic is currently TCP, and TCP has strict ordering > requirements, and even if clever techniques like RACK can make it more robust > against reordering, the applications will see the full latency hit incurred by > re-sorting re-ordered packets in the receivers TCP stack, no? not necessarily. which is going to take longer, having packets sit in a buffer somewhere in the network until they get re-ordered, or having them sit in the buffer on the target machine until they get re-ordered? if there is no resouce contention, they should be equal. In practice, since the network devices are more likely to run into resource contention (think locking overhead between cores if nothing else), it can easily be faster to sort them at the destination. David Lang