From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 43DFC21F3DF for ; Fri, 12 Jun 2015 10:51:30 -0700 (PDT) Received: from u-083-c193.eap.uni-tuebingen.de ([134.2.83.193]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LbdiB-1ZR0cV0A6F-00lC5p; Fri, 12 Jun 2015 19:51:28 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sebastian Moeller In-Reply-To: Date: Fri, 12 Jun 2015 19:51:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6AD8E150-5751-43AC-8F6C-8175C1E92DE1@gmx.de> To: Benjamin Cronce X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:M1JOHImHsnN5yzf03l7TdIdKiovphSNIYh93ItiQhKPzqmsuzSH 8HV0VjzgGQIAAV2cnWeSBW20W5DxtU/5AtYmquGbI8mICFvL93l/M8uTL8XQ1P39CX02dfv TDAB+jThr5D2DvJJ0sE7TdWItFMUOt49CfSRB1FUCQbXTkawKLO6EDMsVzxItnSM9WT0W+I U4qw0U7KJDfUL2/56kKsg== X-UI-Out-Filterresults: notjunk:1;V01:K0:V2RmZmjMmwg=:wcOE27khqJVElWHwNYuQ8S 6voeivxvDTFN+Cxech6tPB0EuaVAi4VNpgaJ0wXcOmYgWJXC6DiQvvFoGHsbwOwjqBlbefri+ A2Ad6L96XP47BmzGSnxYjUw2jcptXSlLAED9bGPNlNED8Io/kg3uscgEQxnLEb3UhgXoUdbKy HPs4+DhawDUpAeXvmcnh7zlBXaEWns2o+v7wK5Kosy6UdJ7k4ZRmi3P1nL3ZPD8g/6ndWTrCm kGl8yxCD2KauG5JNdDiqI0tcCepqW0Lk/6y290kCWES6ewAQqq3GOx0Ur+YJETQGzxnquu4A3 VKbvWFM1MMdxibk9hNuS09MzkDsuuqmK0+gFa5Ep0rwcS54Gbw8zuKeiglbeA08EbIPYYiAGT kWSLXMj2SiJhlH+eJXamieB3KyVSvMiitpOF0MIoznLqkpDSnS14Avh/HwFB9EJ/a8X1SP1p1 ZCBa7FG3pYJRJMUXGbZVpRht0tfTie1yJvKcggFEqCySbUaD0rBQDCSf0zZbewWiRYvrusE0T PZpJJv2AgfCF8AWIglAKRmNMpp9rKfXra4lH/PBY02gQ4xq+zSf2wmx4q6lszSKwib1Tc6WaG eL4k757HIXBxy2G733a/OY8yI3jMgq8BdHc79bYmfTiyFYlMpF3Y+eOcxp2LxRcUIZXr1UJ4w tk4j0BWFt40/gVSAyx/yT/FIlC7K5AQaQmzfZgbXB2bl8WiA89JkdxJF5jJz7bEj5hSI= Cc: bloat@lists.bufferbloat.net Subject: Re: [Bloat] Bloat done correctly? X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 17:52:00 -0000 Hi Benjamin, On Jun 12, 2015, at 17:33 , Benjamin Cronce wrote: > > On Fri, Jun 12, 2015 at 4:08 AM, Sebastian Moeller wrote: > > Hi Benjamin, > >=20 > > To go off onto a tangent: > >=20 > > On Jun 12, 2015, at 06:45 , Benjamin Cronce wrote: > >=20 > > > [...] > > > Under load while doing P2P(About 80Mb down and 20Mb up just as I = started the test) > > > HFSC: P2P in 20% queue and 80/443/8080 in 40% queue with ACKs = going to a 20% realtime queue > > > http://www.dslreports.com/speedtest/622452 > >=20 > > I know this is not really your question, but I think the = ACKs should go into the same queue as the matching data packets. Think = about it that way, if the data is delayed due to congestion it does not = make too much sense to tell the sender to send more faster (which = essentially is what ACK prioritization does) as that will not really = reduce the congestion but rather increase it. > > There is one caveat though: when ECN is used it might make = sense to send out the ACK that will signal the congestion state back to = the sender faster=85 So if you prioritize ACKs only select those with an = ECN-Echo flag ;) > > @bloat : What do you all think about this refined ACK = prioritization scheme? > >=20 > > Best Regards > > Sebastian >=20 > Here's a very real problem for many users. If you have a highly = asymmetrical connection like what many DSL and cable users have, doing = even mild uploading can consume enough bandwidth to affect your ability = to upload ACKs, which can negatively affect your downloads. > A regular offender to many is P2P. If you're uploading while = downloading on a 30/3 connection, you may not be able to ACK data fast = enough. Of course this is in of itself mostly an issue caused by = bufferbloat and/or lack of fair queueing. I agree, but I think reducing buffer bloat and using fair = queueing is superior to ACK prioritization, that=92s all. >=20 > I guess the real question is, should ACKs be prioritized in a system = that does not exhibit bufferbloat or has fair queuing that allows the = ACKs to not feel the affect of other bandwidth being consumed. With no = data to back this up, my first guess would be it will not matter. If you = have no bufferbloat or you have fair queuing, the ACKs should = effectively be sent nearly immediately. Actually fq_codel mildly boosts sparse flows, and since ACK = typically are sparse they usually do not suffer. But all sparse or = starting flows get the same treatment, so nothing ACK specific just = something that typically works well.=20 > One case where it could make a difference if where ACKs make up a = sizable portion of the upload bandwidth if download is saturated. An = example would be a hyper-asymmetrical connection like 60/3. Okay, I will bite, at one ACK every 2 full MSS send, ACKs take = up roughly 2% of the reverse traffic, so at 60 the ACK will cost 60*0.02 = =3D 1.2 or 100*1.2/3 =3D 40%, and I agree that is most likely will cause = problems for people using smaller priority queues. It is also one reason = why I have read recommendations to size priority classes equally = (percentage wise) for up- and download, and make sure ACKs get the same = priority as the reverse data... > In this case, having the ACKs in a separate queue would actually do = the opposite, it would put an upper bound on how much bandwidth ACKs = could consume unless you gave your ACK queue nearly all of the = bandwidth. Well, as stated above if your incoming traffic class allows 100% = bandwidth use the corresponding outgoing class would better allow the = same percentage=85 So i still think not putting ACKs in higher = priorities gives better overall system balance. BUT I have no experience = with P2P traffic, so things could be different there. I would hope to be = able to tell my P2P apps to mark their packets as background priority, = so the data and ACKs would move out of the way of more urgent traffic. I = understand that you have actual P2P experience so take my input with a = grain of salt, please... Best Regards Sebastian >=20 > In the two examples that I could quickly think of, either it made = little difference or it did the opposite of what your proposed. Of = course it depends on the configuration of the shaping. >=20 > Minor side tangent about bloat and ACKs that doesn't really need a = discussion >=20 > A few months back I was downloading some Linux torrents when I noticed = I was getting packetloss. I pretty much never get packetloss. I also = noticed that I was receiving a fluctuating 100Mb/s-103Mb/s of ingress on = my WAN but only seeing about 80Mb/s of egress on my LAN. I did a packet = capture and saw something funny. My WAN was sending out a lot of Dup ACK = packets. > I grabbed a few of the dest IPs that my firewall was sending to and = did a trace route. Nice low pings for most of the path, then suddenly = about 2-3 hops before the seeder in case their ISP's network, I started = to see huge jitter and pings, in the 1sec-3sec range. Cox and Comcast = were the two main offenders but they do represent a sizable portion of = the population. > My conclusion was bufferbloat was so bad on their networks that the = seeders where not getting ACKs from me in a timely fashion, so they = resent the segments assuming they were lost. This issue was so bad that = about 20Mb/s of the 100Mb/s was duplicate data segments. I was being = DDOS'd by bufferbloat. >=20 > P.S. I removed the emails because I was not absolutely sure if they = would be scrubbed.