Many ISPs need the kinds of quality shaping cake can do
 help / color / mirror / Atom feed
From: Bill Woodcock <woody@pch.net>
To: "Dave Täht" <dave.taht@gmail.com>
Cc: "Network Neutrality is back! Let´s make the technical aspects
	heard this time!" <nnagain@lists.bufferbloat.net>,
	libreqos <libreqos@lists.bufferbloat.net>,
	NANOG <nanog@nanog.org>
Subject: Re: [LibreQoS] transit and peering costs projections
Date: Sun, 15 Oct 2023 09:40:16 +0200	[thread overview]
Message-ID: <83F0052F-F7D3-45BE-AB02-9FBA20217EFA@pch.net> (raw)
In-Reply-To: <CAA93jw5CqXvn0-CwbDpBxQ2WRcEMQmCSU2+LK6aqxVzZwKt2xA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2375 bytes --]

> On Oct 15, 2023, at 01:01, Dave Taht <dave.taht@gmail.com> wrote:
> I am under the impression that many IXPs remain very successful,

I know of 760 active IXPs, out of 1,148 total, so, over 31 years, two-thirds are still successful now.  Obviously they didn’t all start 31 years ago, they started on a gradually-accelerating curve.  I guess we could do the visualization to plot range of lifespans versus start dates, but we haven’t done that as yet.

> states without them suffer

Any populated area without one or more of them suffers by comparison with areas that do have them.  States, countries, cities, etc.  There are still a surprising number of whole countries that don’t yet have one.  We try to prioritize those in our work:

https://www.pch.net/ixp/summary

> I also find the concept of doing micro IXPs at the city level, appealing, and now achievable with cheap gear.

This has always, by definition, been achievable, since it’s the only way any IXP has ever succeeded, really.  I mean, big sample set, bell curve, you can always find a few things out at the fringes to argue about, but the thing that allows an IXP to succeed is good APBDC, and the thing that most frequently kills IXPs is over-investment.  An expensive switch at the outset is a huge liability, and one of the things most likely to tank a startup IXP.  Notably, that doesn’t mean a switch that costs the IXP a lot of money: you can tank an IXP by donating an expensive switch for free.  Expensive switches have expensive maintenance, whether you’re paying for it or not.  Maintenance means down-time, and down-time raises APBDC, regardless of whether you’ve laid out cash in parallel with it.

> Finer grained cross connects between telco and ISP and IXP would lower latencies across town quite hugely...

Of course, and that requires that they show up in the same building, ideally with an MMR.  The same places that work well for IXPs.  Interconnection basically just requires a lot of networks be present close to a population center.  Which always presents a little tension vis-a-vis datacenters, which profit immensely if there’s a successful IXP in them, but can never afford to locate themselves where IXPs would be most valuable, and don’t like to have to provide free backhaul to better IXP locations.

                                -Bill


[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  parent reply	other threads:[~2023-10-15  7:40 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-14 23:01 Dave Taht
2023-10-15  0:25 ` [LibreQoS] [NNagain] " Dave Cohen
2023-10-15  3:45 ` [LibreQoS] " Tim Burke
2023-10-15  4:03   ` Ryan Hamel
2023-10-15  4:12     ` Tim Burke
2023-10-15  4:19       ` Dave Taht
2023-10-15  4:26         ` dan
2023-10-15  7:54       ` Bill Woodcock
2023-10-15 13:41   ` Mike Hammett
2023-10-15 14:19     ` Tim Burke
2023-10-15 16:44       ` dan
2023-10-15 16:32   ` Tom Beecher
2023-10-15 19:19     ` Tim Burke
2023-10-15  7:40 ` Bill Woodcock [this message]
2023-10-15 12:40 ` Jim Troutman
2023-10-15 14:12   ` Tim Burke
2023-10-15 13:38 ` Mike Hammett

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/libreqos.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83F0052F-F7D3-45BE-AB02-9FBA20217EFA@pch.net \
    --to=woody@pch.net \
    --cc=dave.taht@gmail.com \
    --cc=libreqos@lists.bufferbloat.net \
    --cc=nanog@nanog.org \
    --cc=nnagain@lists.bufferbloat.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox