Re: [Cake] inbound cake or fq_codel shaping fails on cable on netflix reno

[Sebastian Moeller <moeller0@gmx.de>]

Hi Dave,

To follow you on this tangent ;)

I have come to the conclusion that the question about whether PtP is better or GPON heavily depends on who is paying.
For a local community like Amsterdam the goal probably was to be able to accommodate as many possible network topologies as possible so that the ISPs that were supposed rent the "dark fiber" can implement any topology they desire. And since it is trivial to use a passive splitter in the CO building to reduce PtP to PtMP, PtP is the way to go. 
For an (incumbent) ISP however, especially a heavily regulated one, the goal is slightly different: build the cheapest network allowing to sell the desired speed-grades while makeing sharing as hard as possible.
The cost of the build-out becomes more important (ISPs are typically publicly traded and have much shorter amortization horizons than a city government (I blame the short-sightedness of investors and the way management pay typically is linked to short-term stock performance, but I digress)) and I have seen numbers that show that GPON gear really is cheaper than AON gear for the same number of customers (it also is less capable, but that is beside the point).
But the kicker, at least in Germany seems to be that the incumbent really really wants to avoid to end in a situation where it can be forced to hand over physical last-mile links to the competition, exactly what is possible with a PtP set-up (the competitor puts its own fiber ethernet switch into the CO, and the ISP that build the network only gets a tiny fixed "rent" per month). 
Finally the GPON standards are made by ITU and hence by the telco community while ethernet is in the hands of the ieee and telco's have less standing there to get their wishes, but I am not sure how important that point really is.

My conclusion is, that it seems immensely sub-optimal to have incumbent ISPs do the local network build-out as what they will build is not ideally suited to what the community served actually wants. This conclusion is also backed by the number of state laws that have cropped up over time making community-initiated and financed network build-out as hard as possible, indicating that the telco lobbyists share my assessment about which network ownership (and topology) actually serves the end-customers best ;)



Best Regards
	Sebastian


> On Jul 23, 2018, at 16:56, Dave Taht <dave.taht@gmail.com> wrote:
> 
> Great info, thx. Using this opportunity to rant about city-wid
> networks, I'd have done something so different
> than what the governments and ISPs have inflicted on us, substituting
> redundancy for reliability.
> 
> I'd have used bog standard ethernet over fiber instead of gpon. The
> only advantages to gpon were that it was a standard normal folk
> (still) can't use, it offered encryption to the co-lo, and the gpon
> splitter at the neighborhood cabinett could be unpowered, and a
> telco-like design could be made telco-level reliable.Theoretically. In
> reality it constrains the market and raises the price of gpon capable
> gear enormously, thus creating a cost for the isp and a healthy profit
> margin for the fiber vendor.
> 
> Neighborhood cabinets would be cross connected north, east, west,
> south, uplink1, uplink2, thus rendering the entire network immune to
> fiber cuts and other disruptions of service and allowing competition
> for service from multiple isps. Fiber or copper or wireless (cell) to
> the building from there. Your neighbor would be one hop away. Local
> cellular or wifi would spring out of smaller towers distributed above
> those cabinets.
> 
> Lest you think I'm entirely insane, that's how amsterdam's network was
> built out 10+ years ago.
> https://arstechnica.com/tech-policy/2010/03/how-amsterdam-was-wired-for-open-access-fiber/
> 
> I'd have avoided MPLS, and gone with something like 64xlat to deal
> with the ipv4 distribution problem. There'd be a secure routing
> protocol holding the city-wide network together. And there'd be
> ponies. Lots of ponies.
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake