<font face="arial" size="2"><p style="margin:0;padding:0;">One other thing that worries me is this:  if you have 100 TCP connections all trying to get through a congested link, each "drop" signals only one of those connections that there is a need to cut the receive window size (by a factor of 2).   So if each of the 100 connections has a window size that corresponds to the bitrate-delay-product of the channel, you need on the order of 100 log2(100) ~ 650 drops to "fairly" slow all of the 100 connections down to each have a bitrate-delay-product equal to the 1/100 fair share, at minimum.  Because of this: you have to signal all 100 independent end-to-end control loops enough times to slow their rate.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">Avoiding "drops" means that it takes much longer to get to the right, relatively fair, operating point.   And even if you are near the right operating point already, being selective on drops is pretty "unfair" in a statistical sense.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">Also, remember that "fair" should not try to give capacity to TCP connections that are already constrained by other bottleneck links.   You can't give them capacity, usefully - doing so creates buffer "inflation" pressures on those links, which causes unnecessary oscillation in the other links.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">Remember that the Internet is not at a "stable equilibrium" ever - "waves" flow through it, and the goal is to not "amplify" the waves.   The end-to-end control loops are the damping functions, while the link queue management (with drops and ECN) merely provide signals and keep latency short.  They can't "damp" traffic and may amplify if they try misguidedly to damp out waves.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">-----Original Message-----<br />From: "Dave Taht" <dave.taht@gmail.com><br />Sent: Friday, August 24, 2012 4:08am<br />To: dpreed@reed.com<br />Cc: "Dave Täht" <dave.taht@bufferbloat.net>, cerowrt-devel@lists.bufferbloat.net, codel@lists.bufferbloat.net<br />Subject: Re: [Cerowrt-devel] [PATCH 2/2] codel: reduce count after exiting dropping state after one maxpacket<br /><br /></p>
<div id="SafeStyles1345821168">
<p style="margin:0;padding:0;">On Thu, Aug 23, 2012 at 12:17 PM,  <dpreed@reed.com> wrote:<br />> I would be cautious about cutting down the information rate to TCP.<br />> Remember the collection of TCP pairs are already seeking this information.<br />> You risk driving TCP's control loop crazy, especially if you end up<br />> "resonating" with it with positive feedback.<br /><br />We have been wrestling what we call s3 (re-entering dropping state)<br />for a very long time. From k&v's current test ns2 code:<br /><br />https://github.com/dtaht/ns2/blob/master/queue/codel.cc<br /><br />...<br /><br /> r = dodeque();<br /> dropping_ = 1; // mdt: thought was to to change this to r.ok<br /> // and do something mildly different below<br /><br /> // If min went above target close to when it last went below,<br /> // assume that the drop rate that controlled the queue on the<br /> // last cycle is a good starting point to control it now.<br /> // Unfortunately, this is not easy to get at. "n*interval" is<br /> // used to indicate "close to" and values from 2 - 16 have been<br /> // used. A value of 8 has worked well. The count value doesn't<br /> // decay well enough with this control law. Until a better one<br /> // is devised, the below is a hack that appears to improve things.<br /><br /> if(count_ > 2 && now- drop_next_ < 8*interval_) {<br /> count_ = count_ - 2;<br /> // kmn decay tests // mdt - floating point is not an option!<br /> if(count_ > 126) count_ = 0.9844 * (count_ + 2);<br /><br /> } else<br /> count_ = 1;<br /> drop_next_ = control_law(now);<br /> }<br /> return (r.p);<br /><br /><br /><br />><br />><br />><br />> Rather than focus on "precision" or "stability" at the contended resource,<br />> remember the point is to minimize latency on an end-to-end basis so that all<br />> the TCP's can have tight control loops.  Thus there is no "goal" to making<br />> the contended queue maximized in capacity.  The goal is that it should drain<br />> quickly, which means keeping it small!   The goal is (as the codel paper<br />> says) to use the *minimum* latency as the estimator, not the "average" or<br />> weighted (delayed) average.<br />><br />><br />><br />> Keep focused on the control theory principles, NOT on throughput<br />> maximization.  If you push toward maximizing throughput at any cost, even<br />> with codel, you will end up with *large* excursions in latency that stick<br />> for a long time.  I.e. bufferbloat.<br /><br />I might argue from a control theory perspective that we're not banging<br />on or observing all the right things.<br /><br />I was dubious about the value of the 2nd patch, given the more<br />aggressive decline in drop probability I already had vs a vs the ns2<br />code, (which was admittedly far less aggressive than the original<br />linux code). Might retain<br />the idea, flip it around some more, certainly plan to scratch head a<br />lot... was glad to figure out newton didn't run in reverse that well,<br />tho.<br /><br />Anyway, in my limited testing today the 3rd version of the patches<br />worked fine at short RTTs and at a range of bandwidths from 1Mbit to<br />100Mbit, but that's the easy part and plenty more fiddling remains<br />with more streams and longer RTTs.<br /><br />http://snapon.lab.bufferbloat.net/~d/fq_codel/rtts.png<br /><br />(It's also somewhat weird getting used to nearly perfect<br />bi-directional utilization all the time in fq_codel - no matter what<br />underlying version<br />of codel is there)<br /><br />Incidentally there is this 10 second periodicity to my captures that bothers me<br /><br />http://snapon.lab.bufferbloat.net/~d/fq_codel/alwaysthoughtthese10secondintervalswereaflawofthecapturetoolbut.png<br /><br />Anyway<br /><br /><br /><br />><br />> -----Original Message-----<br />> From: "Dave Täht" <dave.taht@bufferbloat.net><br />> Sent: Thursday, August 23, 2012 9:58am<br />> To: cerowrt-devel@lists.bufferbloat.net<br />> Subject: [Cerowrt-devel] [PATCH 2/2] codel: reduce count after exiting<br />> dropping state after one maxpacket<br />><br />> From: Dave Taht <dave.taht@bufferbloat.net><br />><br />> At a knife's edge, where we are rapidly entering and existing<br />> a dropping state, seek lower to find the optimimum.<br />> ---<br />> include/net/codel.h | 3 +++<br />> 1 file changed, 3 insertions(+)<br />><br />> diff --git a/include/net/codel.h b/include/net/codel.h<br />> index dbfccb7..5e85632 100644<br />> --- a/include/net/codel.h<br />> +++ b/include/net/codel.h<br />> @@ -342,6 +342,9 @@ static struct sk_buff *codel_dequeue(struct Qdisc *sch,<br />> vars->drop_next = codel_control_law(vars->drop_next,<br />> params->interval,<br />> vars->rec_inv_sqrt);<br />> + } else { /* we dropped out of the dropping state in 1 pkt */<br />> + vars->count = vars->count > 1 ? vars->count - 1 : 1;<br />> + codel_Newton_step(vars);<br />> }<br />> }<br />> end:<br />> --<br />> 1.7.9.5<br />><br />> _______________________________________________<br />> Cerowrt-devel mailing list<br />> Cerowrt-devel@lists.bufferbloat.net<br />> https://lists.bufferbloat.net/listinfo/cerowrt-devel<br />><br />><br />> _______________________________________________<br />> Cerowrt-devel mailing list<br />> Cerowrt-devel@lists.bufferbloat.net<br />> https://lists.bufferbloat.net/listinfo/cerowrt-devel<br />><br /><br /><br /><br />-- <br />Dave Täht<br />http://www.bufferbloat.net/projects/cerowrt/wiki - "3.3.8-17 is out<br />with fq_codel!"</p>
</div></font>