<div dir="ltr"><div class="gmail_extra">> On 12/06/15 02:44, David Lang wrote:</div><div class="gmail_extra">> > On Thu, 11 Jun 2015, Sebastian Moeller wrote:</div><div class="gmail_extra">> ></div><div class="gmail_extra">> >></div><div class="gmail_extra">> >> On Jun 11, 2015, at 03:05 , Alan Jenkins </div><div class="gmail_extra">> >> <alan.christopher.jenkins at <a href="http://gmail.com">gmail.com</a>> wrote:</div><div class="gmail_extra">> >></div><div class="gmail_extra">> >>> On 10/06/15 21:54, Sebastian Moeller wrote:</div><div class="gmail_extra">> > >>></div><div class="gmail_extra">> >>> One solution would be if ISPs made sure upload is 100% provisioned. </div><div class="gmail_extra">> >>> Could be cheaper than for (the higher rate) download.</div><div class="gmail_extra">> >></div><div class="gmail_extra">> >>     Not going to happen, in my opinion, as economically unfeasible </div><div class="gmail_extra">> >> for a publicly traded ISP. I would settle for that approach as long </div><div class="gmail_extra">> >> as the ISP is willing to fix its provisioning so that </div><div class="gmail_extra">> >> oversubscription episodes are reasonable rare, though.</div><div class="gmail_extra">> ></div><div class="gmail_extra">> > not going to happen on any network, publicly traded or not.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Sorry if this is a tangent from where the current discussion has gone, but I wanted to correct someone saying something is "impossible".</div><div class="gmail_extra"><br></div><div class="gmail_extra">Funny this was discussed. My ISP sells all packages as symmetrical, "dedicated", and business grade. They define "dedicated" as never oversubscribed. They do oversubscribe the trunk, obviously, but from the last mile to the core, no oversubscription.</div><div class="gmail_extra">It's a small ISP, so one of the times that I called on the weekend, I get a senior network engineer that answered the support line. He told me they did try oversubscription when they first rolled out DSL, but managing congestion is a huge waste of time and increased customer support calls.</div><div class="gmail_extra">They eventually went "dedicated" and never looked back. Support calls were reduced enough to make it worth their while.</div><div class="gmail_extra"><br></div><div class="gmail_extra">In their ToS, they have a net neutrality promise to NEVER block, shape, degrade, or prioritize any traffic, including their own or their partner's.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I can understand taking this approach with 1Mb DSL or even 50Mb fiber where your uplinks are magnitudes faster. I don't know if they can continue this approach into the 1Gb and future 10Gb PON speeds.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Prices: $40 for 20/20, $70 for 70/70, $90 for 100/100, $200 for 250/250, /29 static block for $10/m available for all packages. And no extra/hidden fees. Those prices are exactly what you pay, plus sales tax.</div><div class="gmail_extra">My trace route is a single hop from Level 3, which is their exclusive transit provider. No data caps, "dedicated", told me I should never have congestion and I should always get my provisioned rates and to call if I get anything less than perfect.</div><div class="gmail_extra">I did take them up on this once. I was getting a 20ms ping where I normally got a 13ms ping and I was only getting 45Mb/s on my 50Mb package at the time. I called them, they put me in direct contact with an engineer. 15 minutes later the problem was fixed, 15 minutes after that the engineer called back, told me they were under a DDOS attack and had to activate one of their many failover links to Level 3 to increase their bandwidth.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Another time I was having brief transient packetloss. I called them at 2am saying I was having an issue, they told me they'd have someone at my house to fix the issue asap in the morning. 8am sharp, a knock on the door. Turned out the CAT5e that existed in the house had a bad crimp.</div><div class="gmail_extra"><br></div><div class="gmail_extra">When I signed up for their fiber service, they were still deploying fiber all around the city. They actually gave me a direct personal contact during the entire process. I was called the day before I was supposed to get my connection and was told my dedicated fiber ring had an issue and installation was going to be pushed out a week. </div><div class="gmail_extra">I told them I need the Internet for my job and I just dropped my other provider. I was told they'd call me back. A few hours later, the entire road was filled with a large work crew. They fixed my fiber ring and I got my internet on the day promised. No installation fee.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I guess I went off on this tangent because "Not going to happen, in my opinion, as economically unfeasible" and "not going to happen on any network, publicly traded or not." are too absolute. It can be done, it is being done, it is being done for cheap, and being done with "business class" professionalism. Charter Comm is 1/2 the download speed for the same price and they don't even have symmetrical or dedicated.</div><div class="gmail_extra"><br></div><div class="gmail_extra">P.S. I think I messed up the chain. Sorry. Still getting used to this.</div><div class="gmail_extra"><br></div><div class="gmail_extra">> </div><div class="gmail_extra">> Sure, I'm flailing.  Note this was in the context of AQSM as Daniel </div><div class="gmail_extra">> describes it.  (Possibly misnamed given it only drops.  All the queuing </div><div class="gmail_extra">> is "underneath" AQSM, "in the MAC layer" as the paper says :).</div><div class="gmail_extra">> </div><div class="gmail_extra">> - AQSM isn't distinguishing up/down bloat.  When it detects bloat it has </div><div class="gmail_extra">> to limit both directions in equal proportion.</div><div class="gmail_extra">> </div><div class="gmail_extra">> => if there is upload contention (and your user is uploading), you may </div><div class="gmail_extra">> hurt apps sensitive to download bandwidth (streaming video), when you </div><div class="gmail_extra">> don't need to.</div><div class="gmail_extra">> </div><div class="gmail_extra">> What would the solutions look like?</div><div class="gmail_extra">> </div><div class="gmail_extra">> i) If contention in one direction was negligible, you could limit the </div><div class="gmail_extra">> other direction only.  Consumer connections are highly asymmetric, and </div><div class="gmail_extra">> AQSM is only measuring the first IP hop.  So it's more feasible than </div><div class="gmail_extra">> 100% in both directions.  And this isn't about core networks (with </div><div class="gmail_extra">> larger statistical universes... whether that helps or not).</div><div class="gmail_extra">> </div><div class="gmail_extra">> I'm sure you're right and they're not asymmetric _enough_.</div><div class="gmail_extra">> </div><div class="gmail_extra">> </div><div class="gmail_extra">> ii) Sebastian points out if you implement AQSM in the modem (as the </div><div class="gmail_extra">> paper claims :p), you may as well BQL the modem drivers and run AQM.  </div><div class="gmail_extra">> *But that doesn't work on ingress* - ingress requires tbf/htb with a set </div><div class="gmail_extra">> rate - but the achievable rate is lower in peak hours. So run AQSM on </div><div class="gmail_extra">> ingress only!  Point being that download bloat could be improved without </div><div class="gmail_extra">> changing the other end (CMTS).</div><div class="gmail_extra">> </div><div class="gmail_extra">> ></div><div class="gmail_extra">> > The question is not "can the theoretical max of all downstream devices </div><div class="gmail_extra">> > exceed the upstream bandwidth" because that answer is going to be </div><div class="gmail_extra">> > "yes" for every network built, LAN or WAN, but rather "does the demand </div><div class="gmail_extra">> > in practice of the combined downstream devices exceed the upstream </div><div class="gmail_extra">> > bandwidth for long enough to be a problem"</div><div class="gmail_extra">> ></div><div class="gmail_extra">> > it's not even a matter of what percentage are they oversubscribed.</div><div class="gmail_extra">> ></div><div class="gmail_extra">> > someone with 100 1.5Mb DSL lines downstream and a 50Mb upstream (30% </div><div class="gmail_extra">> > of theoretical requirements) is probably a lot worse than someone with </div><div class="gmail_extra">> > 100 1G lines downstream and a 10G upstream (10% of theoretical </div><div class="gmail_extra">> > requirements) because it's far less likely that the users of the 1G </div><div class="gmail_extra">> > lines are actually going to saturate them (let alone simultaniously </div><div class="gmail_extra">> > for a noticable timeframe), while it's very likely that the users of </div><div class="gmail_extra">> > the 1.5M DSL lines are going to saturate their lines for extended </div><div class="gmail_extra">> > timeframes.</div><div class="gmail_extra">> ></div><div class="gmail_extra">> > The problem shows up when either usage changes rapidly, or the network </div><div class="gmail_extra">> > operator is not keeping up with required upgrades as gradual usage </div><div class="gmail_extra">> > changes happen (including when they are prevented from upgrading </div><div class="gmail_extra">> > because a peer won't cooperate)</div><div class="gmail_extra">> ></div><div class="gmail_extra">> > As for the "100% provisioning" ideal, think through the theoretical </div><div class="gmail_extra">> > aggregate and realize that before you get past very many layers, you </div><div class="gmail_extra">> > get to a bandwidh requirement that it's not technically possible to </div><div class="gmail_extra">> > provide.</div><div class="gmail_extra">> ></div><div class="gmail_extra">> > David Lang</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 12, 2015 at 4:52 AM, MUSCARIELLO Luca IMT/OLN <span dir="ltr"><<a href="mailto:luca.muscariello@orange.com" target="_blank">luca.muscariello@orange.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 06/12/2015 03:44 AM, David Lang wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Thu, 11 Jun 2015, Sebastian Moeller wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On Jun 11, 2015, at 03:05 , Alan Jenkins <<a href="mailto:alan.christopher.jenkins@gmail.com" target="_blank">alan.christopher.jenkins@gmail.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 10/06/15 21:54, Sebastian Moeller wrote:<br>
<br>
One solution would be if ISPs made sure upload is 100% provisioned. Could be cheaper than for (the higher rate) download.<br>
</blockquote>
<br>
    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.<br>
</blockquote>
<br>
not going to happen on any network, publicly traded or not.<br>
<br>
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"<br>
<br>
it's not even a matter of what percentage are they oversubscribed.<br>
<br>
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.<br>
<br>
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)<br>
</blockquote>
<br>
Good points. Let me add a side comment though.<br>
We observe  that fiber users (e.g. 1Gbps/300Mbps access with GPON) are changing behavior<br>
w.r.t. DSL users in the way they use the uplink. This is mostly (not only) due to personal cloud storage availability<br>
and the fact that everyone today is able to produce tons of  big videos, that people are willing to store<br>
outside the home.<br>
As a result it's not unlikely that a backhaul link utilization may get out of the network planning, which is made<br>
on long term statistics. These workloads are unpredictable and if on one hand it's not feasible to<br>
over provision based on such unpredictable long peeks  on the other hand you'd need smart queue<br>
management to cope with such events, where the bottleneck is the backhaul.<br>
<br>
Considering the cost of current equipment upgrades, I feel like very high speed accesses will impose<br>
smart queue management everywhere from the access up to transit links, including the entire backhaul.<br>
Bad news is that no such queuing systems are available in current equipment, so I guess the process<br>
will be pretty slow to happen.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.<br>
<br>
David Lang<br>
_______________________________________________<br>
Bloat mailing list<br>
<a href="mailto:Bloat@lists.bufferbloat.net" target="_blank">Bloat@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/bloat" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/bloat</a><br>
.<br>
<br>
</blockquote>
<br>
_______________________________________________<br>
Bloat mailing list<br>
<a href="mailto:Bloat@lists.bufferbloat.net" target="_blank">Bloat@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/bloat" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/bloat</a><br>
</blockquote></div><br></div>