From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (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 188EB3B2B3; Sun, 26 Jun 2016 23:56:50 -0400 (EDT) Received: by mail-lf0-x236.google.com with SMTP id q132so147864995lfe.3; Sun, 26 Jun 2016 20:56:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=aes/GQGdzrr9c3ocohRTAR92yAhSwCWriydn9K8PeXQ=; b=p9L/ONbaYZRXg39lJZWNV5tCfqbJKmbVyvyR4iElDNeNsJOCT4nNcJtzSKnfb10hYm OLVgK+oSjkawbzSKMvexYrkbxGu9DW/qeSvUFTv7exNiam+dsIwoGHz5h3HqwbDMViti aXs2ooMApuwsV4YOKw7s01Yw2BJvixfkweNdeHQ4PtCizWayPUaXzVCxBJylZsQOmtF2 8cw5TUyxoy5YNnPql+9Q6/YMs1twhzXjxLObkSKuZbZa105zr6aSc9PEGmQJ3Q193/Oi TUaw9VlTStjz+43RBct5gmD/TBRaORtQGB9RS434h0J0Xtj741mcee8LWI6HnFll+yF1 Bg3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=aes/GQGdzrr9c3ocohRTAR92yAhSwCWriydn9K8PeXQ=; b=Yzo0twleYhsXfIK6ngNBhD9QID9P2/bqiy1yTYViXWSmyHkm/2Po43rJZALDu6aGc5 eQkj8WfEJZQZdDEpNio4kMnc58WcXrvGfzFZ0tfD4YQ5gOyhxueP6Iwrth4nZxlCKn6Z qAt+pnAoEVYEabFVAB4u/s3AiO/Mh4bYtcXVBgmP3EoEh1zpAO1+/AfN81fNKaDoPFEA nxljOg4hBsGNU1GrnLthKJUQr7YSloY7mDzTovYUgS+zz/za3EVz2ZTaOU2Pdcm8TJ7F 9QfTl4CbT297K2Qf1svwZ5Yh+2JJCneTU9eeHy/2lXQ3owI0eS0U3KaCpcuXipYbpjtN h9FQ== X-Gm-Message-State: ALyK8tI7/1YLfu7HkNSZN4MaSra63FIvLa9qGfIeVoEkMequmyaq6WnRjIRTdSfOfMm5wA== X-Received: by 10.25.215.20 with SMTP id o20mr3619185lfg.18.1466999808889; Sun, 26 Jun 2016 20:56:48 -0700 (PDT) Received: from bass.home.chromatix.fi (37-33-96-207.bb.dnainternet.fi. [37.33.96.207]) by smtp.gmail.com with ESMTPSA id 80sm2837271lfv.20.2016.06.26.20.56.46 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 26 Jun 2016 20:56:48 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Jonathan Morton In-Reply-To: Date: Mon, 27 Jun 2016 06:56:44 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <6FC1BE74-748D-41C0-A80F-CE2111F20FA8@gmail.com> References: <22371476-B45C-4E81-93C0-D39A67639EA0@gmx.de> <857AEE56-E7DB-4981-B32E-82473F877139@gmail.com> <8AB0D25D-C1CA-45F1-889E-2F73CF8C44F7@gmail.com> <323AFC22-A092-4F59-8197-AF21EF73FD58@gmail.com> <274D3A0FA900FD47AA6B56991AAA32FDC5529FC8@wtl-exchp-1.sandvine.com> <574478B4.7080103@taht.net> <39F38477-A877-4C1B-9B7F-BB3358425F17@gmail.com> <0eb223f9-2873-7f53-c2ce-c6867ddec17c@gmail.com> <48A25043-19E2-4BB7-B634-A4003F7BE6F8@gmail.com> <01BEA343-7C07-46FA-8DC4-07BF26309FC8@gmail.com> <10d58240-e106-ff1f-a038-df5bc0ee7a36@gmail.com> <1465062599.2968.11.camel@edumazet-glaptop3.roam.corp.google.com> To: cake@lists.bufferbloat.net, "codel@lists.bufferbloat.net" X-Mailer: Apple Mail (2.3124) Subject: Re: [Codel] [Cake] Proposing COBALT X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 03:56:50 -0000 > On 4 Jun, 2016, at 22:55, Jonathan Morton = wrote: >=20 > COBALT should turn out to be a reasonable antidote to sender-side = cheating, due to the way BLUE works; the drop probability remains steady = until the queue has completely emptied, and then decays slowly. = Assuming the congestion-control response to packet drops is normal, BLUE = should find a stable operating point where the queue is kept partly full = on average. The resulting packet loss will be higher than for a dumb = FIFO or a naive ECN AQM, but lower than for a loss-based AQM with a = tight sojourn-time target. >=20 > For this reason, I=E2=80=99m putting off drafting such an explanation = to Valve until I have a chance to evaluate COBALT=E2=80=99s performance = against the faulty traffic. The COBALTified Cake is now working quite nicely, after I located and = excised some annoying lockup bugs. As a side-effect of these fixes = (which introduced a third, lightly-serviced flowchain for =E2=80=9Cdecayin= g flows=E2=80=9D, which are counted as =E2=80=9Csparse=E2=80=9D in the = stats report), the sparse and bulk flow counts should be somewhat less = jittery and more useful. I replaced the defunct =E2=80=9Clast_len=E2=80=9D stat with a new = =E2=80=9Cun_flows=E2=80=9D, meaning =E2=80=9Cunresponsive flows=E2=80=9D, = to indicate when the BLUE part of COBALT is active. This lights up = nicely when passing Steam traffic, which no longer has anywhere near as = detrimental effect on my Internet connection as it did with only Codel; = this indicates that BLUE=E2=80=99s ECN-blind dropping is successfully = keeping the upstream queue empty. (Of course it wouldn=E2=80=99t help = against a UDP flood, but nothing can do that in this topology.) While working on this, I also noticed that the triple-isolation logic is = probably quite CPU-intensive. It should be feasible to do better, so = I=E2=80=99ll have a go at that soon. Also on the to-do list is = enhancing the overhead logic with new data, and adding a three-class = Diffserv mode which Dave has wanted for a while. I=E2=80=99ve also come up with a tentative experimental setup to test = the =E2=80=9C85% rule=E2=80=9D more robustly than the Chinese paper = found recently. I should be able to do it wth just three hosts, one = having dual NICs, and using only Cake and netem qdiscs. Now if only the sauna were not the *coolest* part of my residence right = now=E2=80=A6 - Jonathan Morton