From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com [209.85.214.43]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 310C2201261 for ; Tue, 4 Sep 2012 11:50:29 -0700 (PDT) Received: by bkty15 with SMTP id y15so4207696bkt.16 for ; Tue, 04 Sep 2012 11:50:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; bh=TP+m4zUhSC9xjxQ1AehOqRH3ubu2tHdbboTMwn7cshw=; b=A8C7mkt6LI7HPmcDheu0bsRb1k644u+MB7OP9Y0aLSwD11bs7zj/T0ghbPUNlTM3vR SHDR+WUiP3OH3Nh6NtBrDBI/KDii7A588e9LULnMUVBa+YirCx+NlDwukr+m2tNw7aJA XPDroA2CrbDlOAL3KWM821vR+KqmQdp0n1dD5Xrm7+FHhPj8xniv1H60Fq0LX+mtQZ5e lnGI4GZoGKk9sq/KT6YrZiqpPKH9EBlvZTvee6JDZKOWHIfTZvxTp71Wqm0A/CpVYozp lCAa7hbMP35S30aZ8cmB4h4YmPvEycPJghDhOwij9rWWumWnV3SDtlaLT5MxhjfEsQwK vdmA== Received: by 10.204.149.217 with SMTP id u25mr8539182bkv.107.1346784626774; Tue, 04 Sep 2012 11:50:26 -0700 (PDT) Received: from [192.168.142.158] ([74.125.121.33]) by mx.google.com with ESMTPS id 14sm11216104bkq.12.2012.09.04.11.50.24 (version=SSLv3 cipher=OTHER); Tue, 04 Sep 2012 11:50:25 -0700 (PDT) From: Eric Dumazet To: Dave Taht In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Tue, 04 Sep 2012 20:50:23 +0200 Message-ID: <1346784623.13121.65.camel@edumazet-glaptop> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: codel@lists.bufferbloat.net Subject: Re: [Codel] fq_codel: revenge of the standing queue 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, 04 Sep 2012 18:50:29 -0000 On Tue, 2012-09-04 at 11:35 -0700, Dave Taht wrote: > 2) New flows > > The next issue (at these 10 and 100Mbit rates) is the "new flow" idea > in fq_codel. It is VERY useful pushing sparse flows to the fore of the > queues, and also provided a boost to long RTT flows. However at high > levels of occupancy and low bandwidth, flows empty their queue > rapidly, become "new flows", and then mislead codel for that flow into > resetting itself again, since we end up with a short delay for the > re-entrance. This isn't a particularly horrible behavior, but as my > own hope for this feature was to make voip better primarily, and > everything else we got from it was a bonus. > > TSQ really made this oddity show up big. I think on routed traffic it > will be less of an issue. This is simply not true, and based on misunderstanding on what does fq_codel. A flow never leaves the new flow list before doing a full RR cycle in old flow list (even without any packet in this flow) _IF_ we did a full RR cycle, then we accumulated a full quantum of credit, and lost our rank the 'fq_codel RR queue' (the combination of the 2 internal queues, new and old) Therefore, we allow the flow to be queued in 'new flow', to recover a bit of the lost rank in queue. Basically you dont interpret correctly the 'new_flow_count' counter. It means almost nothing at all, since for a given TCP flow, we _can_ increment this counter several time.