From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vn0-x22f.google.com (mail-vn0-x22f.google.com [IPv6:2607:f8b0:400c:c0f::22f]) (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 13AE021F431 for ; Wed, 3 Jun 2015 08:47:14 -0700 (PDT) Received: by vnbf7 with SMTP id f7so1628878vnb.13 for ; Wed, 03 Jun 2015 08:47:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=T3AFaW35JQSn7p07ZGg5BNgVlZHA59IyWSRHBL1CbnI=; b=iMeKtwghrRq/4gqJTBQuQBtfl0oC1yyZEDbmxH0uh6gAp98KjqXyukCU/PCsLyYcDO roaHaeDvYjyKvlkFXunxNNDjf8h4dy4sGVdpWAoVoM7CLksluRomkBOSS84kX9+FC6kY RlD2wBmQYF8YTyFerjGhNuHO1MGGtfJH8xFETYiM0aysQXlGlfTRBgAcnqcGFcB8gMlU KsMB8703medk3hEBqyb5wtqXDtK2OMBkXz/Fn/Mb9kDhQxhPM3Gbb9gZtbl3p9n51OKN 73ccejhJMZgvIohwJTyJp/Vy4/wCWo0UPs/E3bTShhzF0XWd//tuo4oN+KATUPmyi1oO fJCQ== MIME-Version: 1.0 X-Received: by 10.52.30.201 with SMTP id u9mr47754721vdh.95.1433346433748; Wed, 03 Jun 2015 08:47:13 -0700 (PDT) Received: by 10.52.12.167 with HTTP; Wed, 3 Jun 2015 08:47:13 -0700 (PDT) Received: by 10.52.12.167 with HTTP; Wed, 3 Jun 2015 08:47:13 -0700 (PDT) In-Reply-To: References: Date: Wed, 3 Jun 2015 18:47:13 +0300 Message-ID: From: Jonathan Morton To: Dave Taht Content-Type: multipart/alternative; boundary=bcaec51ba3ab0614f505179ef96c Cc: cake@lists.bufferbloat.net Subject: Re: [Cake] perhaps pursuing sqrt(flows) one day? X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 15:47:43 -0000 --bcaec51ba3ab0614f505179ef96c Content-Type: text/plain; charset=UTF-8 It's important to draw the right conclusions from a paper like that. They ran their experiments using Reno and single drop-tail queues. As we know, FQ and AQM both change those dynamics considerably. I'm also suspicious of any approach which asks me to take a number of flows as an a priori constant; we always need to handle the single flow case unless we can prove otherwise. It is however encouraging to see that the "imperfect" behaviour of a real network (versus a virtual clocked simulator) erases the main argument against pacing, that of synchronisation. Also that the primary throughput benefits are seen in the early phases of a connection, which is where we currently see the biggest bursts (from slow start) and the biggest queues under AQM. They do conclude that a queue sized to BDP/sqrt(flows) is adequate. The corollary, which is probably more practically valid, is that N^2 flows are required to achieve maximum sustained throughput, given Reno and a dumb buffer sized to BDP/N. For FQ, that corresponds to BDP*(flows^-1.5) per queue. Since throughput is also divided evenly between flows, that in turn corresponds to RTT/sqrt(flows) sojourn time. Since I now track the number of active flows directly in cake, it is possible to calculate this correction factor to the Codel parameters when that number changes, using the existing inverse square root code (and, for small numbers of flows, the cache). Before I actually try that, however, I'd like to know whether the "fishcake" iteration of cake works better in the cases you were concerned about. - Jonathan Morton --bcaec51ba3ab0614f505179ef96c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

It's important to draw the right conclusions from a pape= r like that. They ran their experiments using Reno and single drop-tail que= ues. As we know, FQ and AQM both change those dynamics considerably. I'= m also suspicious of any approach which asks me to take a number of flows a= s an a priori constant; we always need to handle the single flow case unles= s we can prove otherwise.

It is however encouraging to see that the "imperfect&qu= ot; behaviour of a real network (versus a virtual clocked simulator) erases= the main argument against pacing, that of synchronisation.=C2=A0 Also that= the primary throughput benefits are seen in the early phases of a connecti= on, which is where we currently see the biggest bursts (from slow start) an= d the biggest queues under AQM.

They do conclude that a queue sized to BDP/sqrt(flows) is ad= equate. The corollary, which is probably more practically valid, is that N^= 2 flows are required to achieve maximum sustained throughput, given Reno an= d a dumb buffer sized to BDP/N.

For FQ, that corresponds to BDP*(flows^-1.5) per queue. Sinc= e throughput is also divided evenly between flows, that in turn corresponds= to RTT/sqrt(flows) sojourn time. Since I now track the number of active fl= ows directly in cake, it is possible to calculate this correction factor to= the Codel parameters when that number changes, using the existing inverse = square root code (and, for small numbers of flows, the cache).

Before I actually try that, however, I'd like to know wh= ether the "fishcake" iteration of cake works better in the cases = you were concerned about.

- Jonathan Morton

--bcaec51ba3ab0614f505179ef96c--