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

Benjamin Cronce bcronce at gmail.com
Mon Jul 23 13:32:49 EDT 2018


I don't know if this is possible for higher density cities, but the fiber
ISP here uses P2P fiber ring from the house all the way back to the CO.
It's only at the CO that they aggregate to the GPON port. This means I do
not share any field fiber with anyone else and the ring design allows for a
single fiber cut to not take out my Internet.

It seems " and allowing competition for service from multiple isps" is the
main point for your described setup. My current setup is fine for my single
ISP, but they don't have to share with anyone else. I have heard of
alternative setups where the CO was not owned by an ISP, but where all the
ISPs hooked into the fiber network. North West East South redundancy sound
overly redundant, but I guess I would not complain. I assume it means
powered equipment in the field, unless there's a way to passively do that
without dropping the signal strength. I would prefer a two point redundant
system that was passive over an active 4 way redundant system that could
have power failures, which are more common than fiber cuts around here. My
firewall has nearly 450 days of uptime, not many power outages either.

I am already one hop away from everyone in the city, including my employer.
The ISP uses a flat network model, everything plugs into the core. The core
router has many ports with a minimum rates of 100Gb. The GPON units plug
directly into the core, and they're only used as layer 2 devices. The GPON
units have 1 or more 100gb or 400gb uplinks. The network is provisioned to
be fully non-blocking. It can handle all customers at 100% of their
provisioned rates at the same time. Other than for redundancy, there's
little reason to have routing/forwarding being done in the field. A "hub"
pattern is fine and scales just fine, and less complex.

I'm not sure one hop away if useful in a multi-ISP shared network since
your packets need to go to your ISP in order to get routed back to your
neighbor.

On Mon, Jul 23, 2018 at 9:56 AM Dave Taht <dave.taht at 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 at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cake/attachments/20180723/e2c4239b/attachment.html>


More information about the Cake mailing list