From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 9A54821F196 for ; Tue, 31 Mar 2015 05:47:48 -0700 (PDT) Received: by lboc7 with SMTP id c7so11452541lbo.1 for ; Tue, 31 Mar 2015 05:47:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NADUeTdLufZRc/l+pJWH82OhgIwPemUgJZli3p4SnzY=; b=V4nLoJhAFQHrpYIIE+aoppoV3vWMkNVB4nvIOTg+zRqKz0Jo4CBmuRX1CYI4htyZ95 VO3A5OrbpI5CeIRvB+3FrqTgCxMwFd2DWhlaaBuxWM8KatUi6ESCcd56UqIeSgq5aEZm t6XoIWub/5Q/TlI1VFrlZ8LFH8PvE09evl9IB0QjcBEhDHXl2tFVK2aEHj3rXFSXeA5/ 2v8ZBEB/Cw8Ny/SUg2Qxg0HLhRUtf+AOWZ8WA4cbsGadSjDpi2YX4Y32ajKyikpG6EnK 1YAp8gQ1rtXdaco3u7GYRFDECd+QAYDcM+Y6SGThs1AXM2v7HVUPMnyHsibXlMUc2rsJ ix5g== X-Received: by 10.152.9.4 with SMTP id v4mr4369152laa.34.1427806065749; Tue, 31 Mar 2015 05:47:45 -0700 (PDT) Received: from bass.home.chromatix.fi (188-67-15-150.bb.dnainternet.fi. [188.67.15.150]) by mx.google.com with ESMTPSA id t3sm300354lag.15.2015.03.31.05.47.43 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 31 Mar 2015 05:47:44 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Jonathan Morton In-Reply-To: <4219E429-4E6F-4CC5-88CA-E33076A4A895@gmx.de> Date: Tue, 31 Mar 2015 15:47:41 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <3355F9ED-19B6-47BF-BC34-C388C2224C05@gmail.com> References: <7081A75C-899A-4DB7-8D77-935A37B362D8@gmail.com> <5509957B.30600@pollere.com> <491C7497-BE3E-452B-A797-C7FC1102E7ED@gmail.com> <750FA673-E20D-4D48-9386-097D32CD31FB@gmail.com> <51665FD7-629A-4B8C-B258-2E9AF8E3B5D0@gmx.de> <8753FC87-8C86-4EFE-A4B6-6EDB82AE5D26@gmail.com> <4219E429-4E6F-4CC5-88CA-E33076A4A895@gmx.de> To: Sebastian Moeller X-Mailer: Apple Mail (2.2070.6) Cc: "codel@lists.bufferbloat.net" Subject: Re: [Codel] The next slice of cake X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 12:48:17 -0000 > On 31 Mar, 2015, at 10:12, Sebastian Moeller wrote: >=20 >>> I thought the main argument was, that interval needs to be roughly = in the right range and target is supposed to be between 5 to 10 percent = of interval. >>=20 >> Yes, but why? >=20 > I think this is explained well in sections 4.3 and 4.4 of = https://datatracker.ietf.org/doc/draft-ietf-aqm-codel/?include_text=3D1 >=20 >> I have seen other arguments, both recently and otherwise, which = modify target to accommodate the MAC grant latency of some medium, while = interval is still described as a rough estimate of the RTT. >=20 > According to Kathleen Nichols = http://pollere.net/Pdfdocs/noteburstymacs.pdf the reasoning of the RFC = draft should also apply to the MAC issue. Cake's shaper has no significant access grant latency (typical = scheduling latency in Linux is on the order of 1ms), so while the = discussion of that case is enlightening, it isn=92t relevant to my work = right now. (Might become relevant in other contexts.) But having just re-read those papers carefully, the argument over target = actually boils down to the fact that - at the time of writing - there = was a special case which would avoid marking or dropping the final MTU=92s= worth of the queue, regardless of the target or latency settings. This = is actually quoted in the I-D as the mechanism by which Codel scales = down to 64Kbps. See "non-starvation drop inhibit=94. That special case is *not* present in the more recent versions of Codel, = including the version used for the original version of cake. Some = versions of Codel have an alternative mechanism, where they special-case = the last packet in the queue rather than the last MTU=92s worth. But = this doesn=92t work very well for cake (or for fq_codel) which often = delivers the last packet in that sub-queue while there are still other = packets in the overall queue - and the latter is what is tested. As a result, I saw truly excessive marking if I selected a very slow = shaping rate (eg. 64Kbps) without adjusting the target. The congestion = window was already at minimum size, so such aggressive congestion = signalling just resulted in reduced throughput and (when talking to = servers without ECN) more retransmissions. So what cake does is to adjust the target to roughly match the behaviour = of that special case, and then adjusts the interval to be compatible = with the revised target and the assumed RTT. Since cake implements = sophisticated flow isolation - which is getting more sophisticated with = each version - a slightly higher sojourn time in fat flows isn=92t a = problem, because sparse flows get to bypass them. One of the things I = really like about flow-queuing and ECN is that it enables smooth, = consistent delivery of the various assets that make up a web page, and = those benefits were noticeably compromised with cake2 (which left out = those adjustments). >> Yes - I could make it capable of dropping multiple packets to cope = better with the latter case. >> Codel already has such a protection mechanism, but I haven=92t yet = converted it to byte mode. >=20 > Ah, good this is one more important step to make smallish routers = survive a udp flood; not that I think a router should work great during = a flood/attack, but it certainly should not crash=85 By the time I read this, I=92d already implemented these. :-) Now to update iproute2 - again - to deal with the new statistics = outputs, and I might be in a position to start sending patches. - Jonathan Morton