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 69E3B3B29E for ; Mon, 3 Dec 2018 04:42:56 -0500 (EST) 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 1gTkkh-0006ly-9c; Mon, 03 Dec 2018 10:42:55 +0100 To: Jonathan Morton , Luca Muscariello Cc: bloat References: <65EAC6C1-4688-46B6-A575-A6C7F2C066C5@heistp.net> <939858e1-eeff-01a3-fd35-fb3d2bbff6f8@kit.edu> From: Mario Hock Message-ID: <956eb5a2-1ac6-ebfc-2e15-b21b8c5aeb3b@kit.edu> Date: Mon, 3 Dec 2018 10:42:50 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 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 1543830175.357426557 Subject: Re: [Bloat] when does the CoDel part of fq_codel help in the real world? 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: Mon, 03 Dec 2018 09:42:56 -0000 Am 30.11.18 um 12:04 schrieb Jonathan Morton: >> On 30 Nov, 2018, at 12:32 pm, Luca Muscariello wrote: >> >> Two last comments: one should always used fluid approximation with care, because they are approximations, >> the real model is more complex. Nobody considers that the RTT varies during the connection lifetime and that ACK can be delayed. >> So CWD increases in a non simple way. > > If I can restate that in a more concrete way: the queue may not drain at a smooth, constant rate. There are several real-world link technologies which exhibit this behaviour - wifi and DOCSIS come to mind, not to mention 3G/4G with variable signal strength. > > - Jonathan Morton That's true. In this case the the BDP of the path changes alongside the bandwidth. Thus, it's pretty hard for a congestion control to have 1*BDP (distributed among all concurrent flows) in flight. I think we would have to work with something like an average sending rate and accept short term queues when throughput drops. With LoLa we can also set a lower bound for the delay. If the delay is below that threshold, we assume the link to be not saturated. This is mainly to filter out noise. But maybe this could be tweaked to cope with such technologies. As far as know, 3G/4G already does queuing per user. Thus, if a user produces some delay (e.g., to be able to use high bandwidths, when it suddenly becomes available), it only affects the user itself. Other user could still focus on lower delays. Best, Mario