From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (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 5A3D93BA8E for ; Wed, 6 Jun 2018 04:55:28 -0400 (EDT) Received: from i72t450mh.tm.uni-karlsruhe.de ([141.3.71.47]) by iramx2.ira.uni-karlsruhe.de with esmtpsa port 587 iface 141.3.10.81 id 1fQUE3-0001SW-AG for ; Wed, 06 Jun 2018 10:55:27 +0200 To: bloat@lists.bufferbloat.net References: <152717340941.28154.812883711295847116.malone@soybean.canonical.com> <4f67f9b3-05a1-8d15-0aee-dfe8ea730d7c@gmail.com> <73c25a21-0ace-b5ee-090e-d06fb3b8dc60@kit.edu> <3F65061F-4F05-4F3F-8A43-FFCC1D27F585@gmail.com> <61E48C91-AEF9-4FF4-9F83-45EC7148EC54@jonathanfoulkes.com> <9675C88A-FCC0-43EB-9C71-CBEFD67408CB@gmx.de> <8360fcc1-002b-11f9-ba7c-7b054840acff@kit.edu> From: Mario Hock Message-ID: <71035d7b-7485-9c61-6548-04fd84ad26cd@kit.edu> Date: Wed, 6 Jun 2018 10:55:27 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de esmtpsa 1528275327.373461578 Subject: Re: [Bloat] [Bug 1436945] Re: devel: consider fq_codel as the default qdisc for networking 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: Wed, 06 Jun 2018 08:55:28 -0000 Am 06.06.2018 um 10:15 schrieb Sebastian Moeller: > Well, sending a packet incurs serialization delay for all queued up packets, so not sending a packet reduces the delay for all packets that are sent by exactly the serialization delay. If egress bandwidth is precious (so when it is congested and low in comparison with the amount of data that should be send) resorting to congestion signaling by dropping seems okay to me, as that immeiately frees up a "TX-slot" for another flow. If the packet is dropped and the "TX-slot" is freed up, two things can happen: 1. The next packet belongs to the same flow. In this case, a TCP flow has no benefit because head-of-line-block occurs until the packet is retransmitted. (This might be different for loss-tolerant latency-sensitive UDP traffic, though.) 2. The next packet belongs to another flow. Obviously, this flow would benefit. However, the question which flow should be served next should be made by the scheduler, not by the dropper. (In the case of scheduler/dropper combinations, such as fq_codel.) Best, Mario Hock