From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 8BC783B2A4 for ; Mon, 23 Jul 2018 13:33:03 -0400 (EDT) Received: by mail-lj1-x230.google.com with SMTP id f1-v6so1227547ljc.9 for ; Mon, 23 Jul 2018 10:33:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=D/CbFHRgDGrAQkcWgdYql6OOzPpsLrIdZ22PTRSe92g=; b=PE4AJW4ppYygTufYXUAYk1sTj5pn+hrLi0l0pVbGKfJVmV9Dw1DY0WDzX2tyXlDmrp D5HBERkVdbqfl43QQfKKPI6oesG/RZ4Dwfi00qmc7rmSVoYTKkLrdWwT6G9NhTAY/QIX mzzt6Nyf9vBfXXyqBzJOXyHEUlGXFMnEaBOOi8a3ooNK01NP2hHPNgZC34w83EpW9c8t gBoTKoplJ3nuCYwtS8G0f2y4932f/7rty+0w1mFLLEY4B0wsZz6vqrvOuBZqByJON1Bl wvegzA1aARcUx0fDc1SXw+v5tQ5F6JLQOT+w0nz/9/xWUj/mEo4H4uuMsMoJTQPMYCyj F2TA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=D/CbFHRgDGrAQkcWgdYql6OOzPpsLrIdZ22PTRSe92g=; b=etXwD6oPt8AxbSerHWnviT8h+8OhMx74uXe/JeriWrj6PyNqKjdeQRKu4Nf423XQog /l9h25afkBA7Ya3kE8t2mJ6EM8th5bkmW7yWV+WLDpkexy9gYrjo4bf1O+A5VJPBdtcA PpybedstwwPt65Asc5da1mLyVfGKTMODV/fzzdgmS/Q64wshUfufHTImSA65tvqvGETu O1M1dzDcbBfOIfy8AZnZzm4N2ZrLWofFpW6LRN4gjnd0qo7+UFZp4ZG4CtfoxWCfLVMa lncN1iTMN6n+ymP/bSdck7XkXivzxBEtqEC4jCZ5qwOXwNpJZC/4NNtUfDOLX3YbJcTr s6Xw== X-Gm-Message-State: AOUpUlEY79N+2tSF79uFBFm8H3J07BEWzM+d9AJ22wuu8PchcaWiA8HM 47NE+ShfY79nJvGPvrnw1eENOuRFYw/DO6weIFE= X-Google-Smtp-Source: AAOMgpftHlFQB+Ut+CKgR3YatD4/yQNRb2508Vfri4HU3ueiOM6G6Fxu/WtXbrMemDYapKoC0R0ByYfjkouKg4EAq2Q= X-Received: by 2002:a2e:4186:: with SMTP id d6-v6mr9338991ljf.36.1532367180741; Mon, 23 Jul 2018 10:33:00 -0700 (PDT) MIME-Version: 1.0 References: <4C129A60-21D3-4B78-A764-DC8E2CD7E4DF@gmail.com> <6839ba220fe4399eba3620620515fc1dd801a509.camel@gmail.com> In-Reply-To: From: Benjamin Cronce Date: Mon, 23 Jul 2018 12:32:49 -0500 Message-ID: To: Dave Taht Cc: Ryan Mounce , cake@lists.bufferbloat.net Content-Type: multipart/alternative; boundary="0000000000007940f80571ae09b5" Subject: Re: [Cake] inbound cake or fq_codel shaping fails on cable on netflix reno X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 17:33:04 -0000 --0000000000007940f80571ae09b5 Content-Type: text/plain; charset="UTF-8" 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 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 > --0000000000007940f80571ae09b5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't know if this is possible for higher density ci= ties, 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 po= rt. 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 " for service from multiple isps&quo= t; 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 h= eard 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 redundanc= y sound overly redundant, but I guess I would not complain. I assume it mea= ns 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 redu= ndant system that was passive over an active 4 way redundant system that co= uld 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.<= /span>

I am already one hop away from e= veryone in the city, including my employer. The ISP uses a flat network mod= el, everything plugs into the core. The core router has many ports with a m= inimum 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 o= r 400gb uplinks. The network is provisioned to be fully non-blocking. It ca= n handle all customers at 100% of their provisioned rates at the same time.= Other than for redundancy, there's little reason to have routing/forwa= rding being done in the field. A "hub" pattern is fine and scales= just fine, and less complex.

I&= #39;m not sure one hop away if useful in a multi-ISP shared network since y= our packets need to go to your ISP in order to get routed back to your neig= hbor.

On = Mon, Jul 23, 2018 at 9:56 AM 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 netw= ork was
built out 10+ years ago.
https://ar= stechnica.com/tech-policy/2010/03/how-amsterdam-was-wired-for-open-access-f= iber/

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
--0000000000007940f80571ae09b5--