From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 764813B2B3; Mon, 27 Jun 2016 03:59:11 -0400 (EDT) Received: from [172.17.3.79] ([134.76.241.253]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LoE4f-1boYHE3hjV-00gJ1B; Mon, 27 Jun 2016 09:59:09 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: moeller0 In-Reply-To: <6FC1BE74-748D-41C0-A80F-CE2111F20FA8@gmail.com> Date: Mon, 27 Jun 2016 09:59:09 +0200 Cc: cake@lists.bufferbloat.net, "codel@lists.bufferbloat.net" , Eric Dumazet , Andrew McGregor Content-Transfer-Encoding: quoted-printable Message-Id: <062AA5ED-4AE3-49EC-8096-58BBD592F98A@gmx.de> 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> <6FC1BE74-748D-41C0-A80F-CE2111F20FA8@gmail.com> To: Jonathan Morton X-Mailer: Apple Mail (2.2104) X-Provags-ID: V03:K0:n1tNICGdhuO2qpFxZ6gOvdRvDJB6bE4T9n1gdk0URESDq+ljM0H hGpRRDJ+o2Kq/fot1CQRq3IwRECmGUjXjd9nZXHgDeCRcuWTSP0ndL5c72NnZSwwhJiImjd ROAsi21FrqsLwGJ843m8TgFkdBWq8qUT2BVIcDLxL8zNvpxdNfCVst5OZMEHb3BfP9qyouq uWlhRQ5sdSS9C01T9M8Kw== X-UI-Out-Filterresults: notjunk:1;V01:K0:v0l2nqyCzUs=:g3GvHBG/pMMnSSzCCqC6Qa JWg8bA8bAuOVetyqpnBgg9ag2z027zrvSmSeQLsjuqRS4jiFtDkpd7eg5Vy0c+BfuiweADF0L f0/JRfXlulyUs2tKeRNGa5G+u0N6J+OIXb9r4MYEDPfRoCHiCkWS68UntpzMtr7vu7xfcfj5V ed9M+BNfAYtASn+VRXqlOUmnWtUcRQSWPaY+tAVXnwcdfnvGfAHfrWR5kGDx8BCp9yowjf6D7 vLIB9eTHj+84LNrnIW+35lieHJmmxJXyOl4QHLGSArd4Xu+D2rEaznjuksLVFq90VYVrKJHnZ TxJjSzSlgImGqwlSCow7RHcpk1OE75h6MQErS3FVgOlIlaWV3ean8BXaCIiDRAQvsuBskuyNx o8QfWy4oU1wR3IdspNvi0wHNG2BZM75fIUzfADOO20UccldbxDEyhUasvRZJJkYShy5wPTk32 C0khk7mzQ365aYEYiGmy5d+1uEXp7TxCFv9DLkF6xEN5Mz7ZMdTkHIMuuXyO/CKv1oIOhB6h3 y/rnQMlzDY/kK3aXpywIqklz9Jry1J5dOjdXemF1hvubocSJ4ri3+mJ57ElLV5HRy/plR0PUt 0Bg2mZKnEkskraQv+xX9A09ZExJ6M3QUPNu0ks5tIi7RXINOPJomo9UMzSIoP5ZIvDH3lM0ZE U6Tt4n8VdywDjhLrQ5wGwHlhqAdooQyROATQbSyvzKhHEbKMG5mGz/45vQfRoVDVwuqQ2Qoj8 MNel46M5Qzt10/vPYJ6FhFIYat08xajNXoPmszh0+ABk6fkvPmOOFJmqLcxeOxeOPpqtE11sP cCdv0D6 Subject: Re: [Cake] [Codel] Proposing COBALT X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 07:59:11 -0000 Hi Jonathan,=20 all of this sounds great! One question inlined below=E2=80=A6 > On Jun 27, 2016, at 05:56 , Jonathan Morton = wrote: >=20 >=20 >> 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. >=20 > 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. >=20 > 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.) >=20 > While working on this, I also noticed that the triple-isolation logic = is probably quite CPU-intensive. Does this also affect the dual[src|dst]host isolation options? = How do you test this option internally (I am trying to solicit testers = from the openwrt forum, but they are hard to come by and understandably = only want to spent limited time with testing, so the results so far are = tentative at best) > 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, Could I, ask nicely again, that you add something to the = keywords that will easily signify whether the keyword has a side-effect = on the atm encapsulation, please?=20 A lot of our users on openwrt/lede only see the output of =E2=80=9C= tc qdisc add cake help=E2=80=9D at best and the different scopes of the = keywords are simply not easy to understand from that. (The =E2=80=9Cscope=E2= =80=9D of the keywords could be cmade clearer for example by either a = pre-/suffix to the keyword names, like in pppoe-ptm or by using two word = configurations like =E2=80=9Cadsl-overhead pppoe-vcmux=E2=80=9D. I admit = that both being less visually pleasing and concise than the existing = keywords, but clearer to our users). > and adding a three-class Diffserv mode which Dave has wanted for a = while. >=20 > 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. >=20 > Now if only the sauna were not the *coolest* part of my residence = right now=E2=80=A6 Your are in Finland? I envy you for your nice long days=E2=80=A6 Best Regards Sebastian >=20 > - Jonathan Morton >=20 > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake