From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 9F9473CB35 for ; Tue, 27 Nov 2018 07:17:51 -0500 (EST) Received: by mail-lj1-x230.google.com with SMTP id k19-v6so19830623lji.11 for ; Tue, 27 Nov 2018 04:17:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=j8oi6oKBe21j64iLzo4t5UpbP1DO93JUh0XzV+lWXFU=; b=Wlj2hP5jl/QHV/j63QxybGD6ZpFzeECmPblBqTMpJRwffVWzVAh7Hi0J1ws1arffat yKAUImUUl+zzF2zNBIEBZYuMefOYZWPObJ6QwkkvEIoJpZDIEte92VWp0vFG0m5S95Cw +lhNSyRhdg1ijyQkaZ/CUanzO2Swe89G8jZZFtYUcuTp1slf1W9bx17O+/QZmVDHjMsS b80385oOHm4eH2eDaVJJHOocwiQGV682dlcneHDfvWuZu/wyI5EbEU/Pd4Tuw9/8Mpwm zITbLNKdtgUaTGQnbyd90mqfYqTVMK4isnE5QGW006Qr2msbfEc/inC10A1sJRtkktwh oqnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=j8oi6oKBe21j64iLzo4t5UpbP1DO93JUh0XzV+lWXFU=; b=XnDzypLvFa3A65M7qIPIAi9qOUdTvc5xZewGRcem5K3RX1Zdbs6zhOUTvzx8VlrPbP BVp3ZpDP4O/muJXJ8SXhldBeT+P8EEPgyNemX82bqS0YlhYgY6jzjmik6JxHNVm/acba XuxOrBZYvovqVYuIbLtRHDosZlIM1qL5Pqwuzi9nP9gaAlwU653gkFmztV4aSdqhuAcI Eow34FE3a0AiLj1SmNiw74ObM3pw6bEwlx2vnlHucvhaVul3h4zfSJyBpjZGwWCpQ1Q2 br9kx+WDP4NssspEhYRHOFwtXOjA/Gfcpi/VGfBG5/CNou6THWnDcMY6gpGBHe8a63qv ncAQ== X-Gm-Message-State: AA+aEWZgFpYvOXbLYVi7QhXTSLJLFABKZ/G63trv9DUeiNIpHSft8s0V 283mUxz7IdY9n4ZA4V/u74s= X-Google-Smtp-Source: AFSGD/W7NFg8pflCnQH44cgAucBEgCN46i8ZUJVu4QThpXB3KcDv+IsmJ6mL7fd6R0oD0WosX3oCJA== X-Received: by 2002:a2e:7011:: with SMTP id l17-v6mr15595764ljc.147.1543321070437; Tue, 27 Nov 2018 04:17:50 -0800 (PST) Received: from jonathartonsmbp.lan (83-245-236-220-nat-p.elisa-mobile.fi. [83.245.236.220]) by smtp.gmail.com with ESMTPSA id o5-v6sm526852ljh.75.2018.11.27.04.17.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Nov 2018 04:17:49 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jonathan Morton In-Reply-To: Date: Tue, 27 Nov 2018 14:17:48 +0200 Cc: Luca Muscariello , "Bless, Roland (TM)" , bloat Content-Transfer-Encoding: quoted-printable Message-Id: References: <65EAC6C1-4688-46B6-A575-A6C7F2C066C5@heistp.net> <86b16a95-e47d-896b-9d43-69c65c52afc7@kit.edu> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.3445.9.1) 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: Tue, 27 Nov 2018 12:17:51 -0000 > On 27 Nov, 2018, at 1:21 pm, Mikael Abrahamsson = wrote: >=20 > It's complicated. I've had people throw in my face that I need 2xBDP = in buffer size to smoothe things out. Personally I don't want more than = 10ms buffer (max), and I don't see why I should need more than that even = if transfers are running over hundreds of ms of light-speed-in-medium = induced delay between the communicating systems. I think we can agree that the ideal CC algo would pace packets out = smoothly at exactly the path capacity, neither building a queue at the = bottleneck nor leaving capacity on the table. Actually achieving that in practice turns out to be difficult, because = there's no general way to discover the path capacity in advance. AQMs = like Codel, in combination with ECN, get us a step closer by explicitly = informing each flow when it is exceeding that capacity while the queue = is still reasonably short. FQ also helps, by preventing flows from = inadvertently interfering with each other by imperfectly managing their = congestion windows. So with the presently deployed state of the art, we have cwnds = oscillating around reasonably short queue lengths, backing off sharply = in response to occasional signals, then probing back upwards when that = signal goes away for a while. It's a big improvement over dumb = drop-tail FIFOs, but it's still some distance from the ideal. That's = because the information injected by the bottleneck AQM is a crude binary = state. I do not include DCTCP in the deployed state of the art, because it is = not deployable in the RFC-compliant Internet; it is effectively = incompatible with Codel in particular, because it wrongly interprets CE = marks and is thus noncompliant with the ECN RFC. However, I agree with DCTCP's goal of achieving finer-grained control of = the cwnd, through AQMs providing more nuanced information about the = state of the path capacity and/or bottleneck queue. An implementation = that made use of ECT(1) instead of changing the meaning of CE marks = would remain RFC-compliant, and could get "sufficiently close" to the = ideal described above. - Jonathan Morton