From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 0CD8321F1C9; Fri, 12 Jun 2015 05:18:21 -0700 (PDT) Received: from u-083-c193.eap.uni-tuebingen.de ([134.2.83.193]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MTjqS-1Ycx6u21pI-00QOxL; Fri, 12 Jun 2015 14:18:16 +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 14:18:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2ACEC68A-3795-4F7C-BA0F-FBDBA3732566@gmx.de> References: <5578DEE8.6090209@gmail.com> To: David Lang X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:oLYHUl2vowUlnXfoqlCv+UuZQW7HW4/6q68VCd19mAAcx/o8lbJ NF6cD9Go6CMcsCWNXwPCBWmeDRZHhcnhrjgV27xRTrXr4BOrjfwlfPnIfz+gFz4JHtVSdTf FyQel+10IM/kEYigGJGDdLtLuKt2ovB9UNsdPP8tm0Xkdah8VcYUjo11AEQBs+ixiM35k9J B2l8yjIxgnGnKXN1EaPPw== X-UI-Out-Filterresults: notjunk:1;V01:K0:+FsgMomg1zo=:qj9aLADVZqTOVe3F00N3cE v+j5oGUr7VGoq77Wem+8RVbShkmBQniXj0g6Xnx50M7mUWgYtXalF1Tv43nbf5f4gozQ9FSdb Y8/eyXwk9NIr5Ml9TZVPuyZfBPtKAqLwkSSTpAeD7lw1kyC+ySz5Xw5mmt8bQSVdIM+mR2G/Y sPIrOcNfEgZOLVa5+QWqGzexGO/SslLxotbmzPlNUc2VHWXeKIXg2L9H7gjMfQmbrPnQqjmBr RgEWGz9mMv3ov/esQouGCoYlYGRSbB1yV+7KBSmJCj1d1Y3IPjsW53XcIC5KbsEUasSg2iJaE lqM8KEi5/TJHJSWACL21+CVICbTIlxsXr9BuU7KmAU4To0E79+2QQ+x0N9bzlI07OS7tiHf++ WFnaM4CVQl45RnYPsAOESzA7yyUG4IfFeFtwdIVmcTnDecd+Dzmnn1lYMWP+Sba1n4bMybvSY fasD1P0A2Uf0We2DFq7M1WRZ2dD8P3KJmtPD6wBzbjaYUyvqMIUaojKVl1LTFgJV+kTW3Q00e hWFlhzNpF8ZtvbP0emCXyvxIMvpWy92yVgxsKUBW0TWPDFFeNep66FQUItLS2Zads0TFxhM5N BO8NSGMeyyEHBRj4F3PQiwU7v1LloSHaYeVfA5GbzTWgkIqA7NMGPK9+ASvB4z99WNaBzTqZN tlW+wI3gE8uSbX/alt/V1CuibfFaSCqKrq2F+V0ENdxgeGX++4O7gJdXWltbXBUD+poM= Cc: cake@lists.bufferbloat.net, Daniel Havey , "cerowrt-devel@lists.bufferbloat.net" , bloat Subject: Re: [Cake] [Bloat] active sensing queue management 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: Fri, 12 Jun 2015 12:18:50 -0000 Hi David, On Jun 12, 2015, at 03:44 , David Lang wrote: > On Thu, 11 Jun 2015, Sebastian Moeller wrote: >=20 >>=20 >> On Jun 11, 2015, at 03:05 , Alan Jenkins = wrote: >>=20 >>> On 10/06/15 21:54, Sebastian Moeller wrote: >>>=20 >>> One solution would be if ISPs made sure upload is 100% provisioned. = Could be cheaper than for (the higher rate) download. >>=20 >> Not going to happen, in my opinion, as economically unfeasible = for a publicly traded ISP. I would settle for that approach as long as = the ISP is willing to fix its provisioning so that oversubscription = episodes are reasonable rare, though. >=20 > not going to happen on any network, publicly traded or not. >=20 > The question is not "can the theoretical max of all downstream devices = exceed the upstream bandwidth" because that answer is going to be "yes" = for every network built, LAN or WAN, but rather "does the demand in = practice of the combined downstream devices exceed the upstream = bandwidth for long enough to be a problem=94 This is what I meant to convey with =93that oversubscription = episodes are reasonable rare=94 oversubscription here as effective or = realized as compared to potential. I realize this is not what =93over = subscribed" usually means ;). I was aiming at the fact that ISPs nned to = balance their static oversubscription in a way that congestion periods = on the =93nodes=94 (whatever a node is) are are enough that customers do = not jump ship. >=20 > it's not even a matter of what percentage are they oversubscribed. >=20 > someone with 100 1.5Mb DSL lines downstream and a 50Mb upstream (30% = of theoretical requirements) is probably a lot worse than someone with = 100 1G lines downstream and a 10G upstream (10% of theoretical = requirements) because it's far less likely that the users of the 1G = lines are actually going to saturate them (let alone simultaniously for = a noticable timeframe), while it's very likely that the users of the = 1.5M DSL lines are going to saturate their lines for extended = timeframes. I assume that ISPs take such factors into account when desining = their access network initially; but mainly I hope that they actually = track realized congestion periods and upgrade bottleneck equipment to = keep congestion periods rare. >=20 > The problem shows up when either usage changes rapidly, or the network = operator is not keeping up with required upgrades as gradual usage = changes happen (including when they are prevented from upgrading because = a peer won't cooperate) Good point, I was too narrowly focussing on the access link but = peering is another "hot potato=94. Often end users try to use traceroute = and friends and VPNs to uncontested peers to discern access-network = congestion from =93under-peering=94 even though at the end of the day = the effects are similar. Thinking of it I believe that under-peering = shows up more as a bandwidth loss as compared to the combined bandwidth = loss and latency increase often seen on the access side (but this is = conjecture as I have never seen traffic data from a congested peering = connection). >=20 > As for the "100% provisioning" ideal, think through the theoretical = aggregate and realize that before you get past very many layers, you get = to a bandwidh requirement that it's not technically possible to provide. Well, I still believe that an ISP is responsible to keep its = part of a contract by at least offering a considerable percentage of the = sold access bandwidth into its own core network. But 100 is not going to = be that percentage, I agree and I am happy to accept congestion as long = as it is transiently (and I do not mean every evening it gets bad, but = clears up over night, but rather that the ISP increases bandwidth to = keep congestion periods rare)=85 Best Regards Sebastian >=20 > David Lang