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 8ACE33B29E for ; Mon, 26 Nov 2018 16:30:05 -0500 (EST) Received: by mail-lj1-x230.google.com with SMTP id v15-v6so18044726ljh.13 for ; Mon, 26 Nov 2018 13:30:05 -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=71ctllSYlaN2Af4++1NrbHRDi5cT2pyJMSVIHbLss5o=; b=d4+0OUtXh+pCacerHs7p+ZjOwkmSfvAkDHxgEsycavJGEYUxyP99llyH+648Vjffpa bwiJZIDHz0zSgeZnAe3oLdTmR/w4IFtmR5UrGK7L1RNx0U2oYZWGrMKnoWKxLfvcomdg Lj8fvtzrCuFkaqTAG449RcJYsCM8qHumSInuso03sG7K1YiTpRFwPo7OZX9MAaZQMC1m JznWIQSlDNsrzYVDZ/k3/FRYBVZNIMJZVMOfio2tDuKBOXrQ6r35wuhOElsYp2RosZWZ J7VDbqB7hH7OGrePomULa7LkttzPoxBlHmz/UqFwmB5WYHAbYwN5W23+qcWzBAHTcsPv 7I3Q== 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=71ctllSYlaN2Af4++1NrbHRDi5cT2pyJMSVIHbLss5o=; b=AVzI7ubLeltlMMYJiI3JodP8sirbJRtMzTLCtKhMeU8GbduNRvr96JGJkH96LhuAy9 R9sCEjV93UKLoHAP8mqxIkvdjXb94ZdTrl8ErHTxAZQ9pskOrSLrS5WDS7Ns/90z0wMP /1LFwVHPTbsktNTqj60wWHZkSSI+pyrHHg9d5nNyiQC1OORfP2a1S+6cETugZfhN+jg/ mC+n6ATCP4ukq/JV652nxE5i+mC9jGNDiiJYf/G8xiFrYf3VT3WXuFpnoN9Rki9ogAYd JmdfD3iAIwjLYRM5zZ/EkquiVsUXaSBR20yf3Kn/8ketHOXm03yglKBdFd3NHpJK1L1s A1SQ== X-Gm-Message-State: AA+aEWZohLu+Av4hzJCvmMSg/C6M0MWj2Wpy/YtSdjGskjHOO9h7SDSy sVQSXDgc5gOO1yzdsHTfqHkiXKCC X-Google-Smtp-Source: AFSGD/WstF6LNd/cBXEawJXq7VZ4jOXUeQwpbVcpbruxwpe+DYNIri46L3J7n0yvzXRBhygS3XUu9A== X-Received: by 2002:a2e:50d:: with SMTP id 13-v6mr17960241ljf.85.1543267804249; Mon, 26 Nov 2018 13:30:04 -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 r4sm232944lfe.60.2018.11.26.13.30.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Nov 2018 13:30:03 -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: <65EAC6C1-4688-46B6-A575-A6C7F2C066C5@heistp.net> Date: Mon, 26 Nov 2018 23:29:53 +0200 Cc: bloat Content-Transfer-Encoding: quoted-printable Message-Id: References: <65EAC6C1-4688-46B6-A575-A6C7F2C066C5@heistp.net> To: Pete Heist 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: Mon, 26 Nov 2018 21:30:05 -0000 > On 26 Nov, 2018, at 9:08 pm, Pete Heist wrote: >=20 > So I just thought to continue the discussion- when does the CoDel part = of fq_codel actually help in the real world? Fundamentally, without Codel the only limits on the congestion window = would be when the sender or receiver hit configured or calculated rwnd = and cwnd limits (the rwnd is visible on the wire and usually chosen to = be large enough to be a non-factor), or when the queue overflows. Large = windows require buffer memory in both sender and receiver, increasing = costs on the sender in particular (who typically has many flows to = manage per machine). Queue overflow tends to result in burst loss and head-of-line blocking = in the receiver, which is visible to the user as a pause and subsequent = jump in the progress of their download, accompanied by a major = fluctuation in the estimated time to completion. The lost packets also = consume capacity upstream of the bottleneck which does not contribute to = application throughput. These effects are independent of whether = overflow dropping occurs at the head or tail of the bottleneck queue, = though recovery occurs more quickly (and fewer packets might be lost) if = dropping occurs from the head of the queue. =46rom a pure throughput-efficiency standpoint, Codel allows using ECN = for congestion signalling instead of packet loss, potentially = eliminating packet loss and associated lead-of-line blocking entirely. = Even without ECN, the actual cwnd is kept near the minimum necessary to = satisfy the BDP of the path, reducing memory requirements and = significantly shortening the recovery time of each loss cycle, to the = point where the end-user may not notice that delivery is not perfectly = smooth, and implementing accurate completion time estimators is = considerably simplified. An important use-case is where two sequential bottlenecks exist on the = path, the upstream one being only slightly higher capacity but lacking = any queue management at all. This is presently common in cases where = home CPE implements inbound shaping on a generic ISP last-mile link. In = that case, without Codel running on the second bottleneck, traffic would = collect in the first bottleneck's queue as well, greatly reducing the = beneficial effects of FQ implemented on the second bottleneck. In this = topology, the overall effect is inter-flow as well as intra-flow. The combination of Codel with FQ is done in such a way that a separate = instance of Codel is implemented for each flow. This means that = congestion signals are only sent to flows that require them, and = non-saturating flows are unmolested. This makes the combination = synergistic, where each component offers an improvement to the behaviour = of the other. - Jonathan Morton