From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by huchra.bufferbloat.net (Postfix) with ESMTP id A1F0C21F9E1 for ; Tue, 11 Aug 2015 11:50:37 -0700 (PDT) Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by wtl-exchp-2.sandvine.com ([::1]) with mapi id 14.03.0195.001; Tue, 11 Aug 2015 14:50:35 -0400 From: Jeff Weeks To: Jonathan Morton , "codel@lists.bufferbloat.net" Thread-Topic: [Codel] drop state short-circuit... Thread-Index: AdDUWTi+z9YPmBhVTMqSiLkA0ZrNhQAJFzgA///NGaE= Date: Tue, 11 Aug 2015 18:50:33 +0000 Message-ID: <274D3A0FA900FD47AA6B56991AAA32FDC53BB5B1@wtl-exchp-1.sandvine.com> References: <274D3A0FA900FD47AA6B56991AAA32FDC53BB45E@wtl-exchp-1.sandvine.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.214.43] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Codel] drop state short-circuit... 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, 11 Aug 2015 18:51:06 -0000 Thanks! I'm a bit skeptical of 'count' usage in general, yes. Say the codel algorithm is managing a large queue, using the default parame= ters. That queue could fill, and codel would enter the drop state, and we'd then = start dropping packets at 100ms, 70ms, 57ms, 50ms, etc... (i.e., 100/sqrt(c= ount)). If the queue size is reasonable, this converges quickly on the correct drop= rate. However, if the queue is larger, it takes considerably longer to reach the = correct drop rate. I has previously (perhaps incorrectly) thought that the queue size becomes = somewhat irrelevant when using codel, as the queue is effectively managed b= y inspecting packet latencies, rather than blindly queuing and dequeuing, b= ut that's not entirely true, it seems, as there's no limit placed on the en= queue operation. In other words, given a high enough input rate, and a large enough queue, c= odel will still output packets considerably beyond the target ms, no? Put another way -- if the codel algorithm starts in a heavily congested pip= e, it will take many seconds before it can adjust to a 1ms interval (count = would have to rise to 10,000). While adjusting, it's very likely to output= many packets with high latencies. Is this a concern for the algorithm? --Jeff ________________________________ From: Jonathan Morton [chromatix99@gmail.com] Sent: Tuesday, August 11, 2015 1:35 PM To: Jeff Weeks Cc: codel@lists.bufferbloat.net Subject: Re: [Codel] drop state short-circuit... The logic is that if the stored count was effectively controlling the queue= , we want to keep using that value if the network is still under load. If = 16 intervals (1.6 seconds) pass without re-entering drop state, we can assu= me the link is no longer saturated (by this flow) and reset count. I think the value 16 itself is mostly arbitrary. I'm a bit skeptical of the way count is saved and restored in the reference= versions - it's hard to follow. Cake's version explicitly keeps the old v= alue, but halves it, allowing it to grow back to its original value if requ= ired. It would also be reasonable to scale the backoff with time, rather t= han thresholding it. - Jonathan Morton