Page MenuHomePhabricator

Send peering requests to AS with the worst TTFB
Closed, ResolvedPublic

Description

Now that my Autonomous Systems report is out: https://performance.wikimedia.org/asreport/

I was thinking of reaching out to the worst offenders in terms of latency (TTFB) to offer peering when we don't have a peering relationship with them already.

Is there an existing process for this?

I think this list of worst offenders makes sense as a first pass:

https://bgp.he.net/AS12958
https://bgp.he.net/AS8402
https://bgp.he.net/AS20632
https://bgp.he.net/AS6805
https://bgp.he.net/AS4713
https://bgp.he.net/AS2516
https://bgp.he.net/AS7018
https://bgp.he.net/AS701
https://bgp.he.net/AS21928
https://bgp.he.net/AS55644
https://bgp.he.net/AS55410

Related Objects

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

The first step when looking at peering with a provider is to check if we're both present at a common exchange point.
You can see where we are present on https://www.peeringdb.com/net/1365, especially the "Public Peering Exchange Points" list.

From there, we can only peer with AS2516 and AS701.
While we already peer with AS21928.

Very large providers have a tendency to not accept (or even not reply to) peering requests. AS701 actually stopped the only peering we had recently.
I'll reach out to AS2516, but they are not present in Equinix Singapore, while we redirect Japan users to the Singapore cache. (KDDI is mostly Japanese)

We can then dig 1 level deeper, and for ISPs we can't reach directly, try to only have one intermediary AS. For that we need to look at the routing table, then do the same PeeringDB lookup for any AS# in the middle. This becomes tedious to do manually, as in addition to that, a provider can advertise only some prefixes to some peers.

See T186835, where I experimented with automating a similar reporting process.

Thanks for the details. I don't have permission to access T186835

Is this manual work something I can do myself?

(Added you to the task)

In some measure, yes.
Getting the routing table is the most complicated part.
As a one of, I've been SSHing directly to the routers, but this doesn't scale.
In SF, AMS and Singapore we send a copy of our routing table to the RIPE RIS servers, so it's possible to use their APIs to get the AS-PATHS as we see them on those sites.
As a longer term project, we could also host our own route collector. (eg. we're experimenting with collecting routes using pmacct for another project).
PeeringDB also have APIs and a downloadable DB.
I've been using them all on and off, so don't hesitate to ask me if you need info/help.

fgiunchedi triaged this task as Medium priority.Apr 9 2019, 8:38 AM
Gilles lowered the priority of this task from Medium to Low.Apr 30 2019, 12:03 PM

Now that the AS report is collecting more data, I've manually compiled a list of AS we could directly peer with (and don't yet), having checked that we have at least one IX in common.

I've looked at the United States, Russia, France, Germany, Italy, Brazil, United Kingdom, India, Poland, Canada, Japan, Spain.

ASASNIX in common
SprintAS1239AMS-IX, Equinix Ashburn
MCI Communications Services, Inc. d/b/a Verizon BusinessAS2828AMS-IX, Equinix Ashburn
T-Mobile USA, Inc.AS21928Equinix Ashburn
Charter Communications IncAS7843Equinix Ashburn, Equinix Dallas
Cox Communications Inc.AS22773Equinix Ashburn
Charter CommunicationsAS20115Equinix Ashburn, Equinix Chicago, Equinix Dallas
Cablevision Systems Corp.AS6128Equinix Ashburn, Equinix Chicago
Orange S.A.AS5511Equinix Singapore
FastwebAS12874AMS-IX
CLARO S.A.AS4230Equinix Ashburn
British Telecommunications PLCAS5400AMS-IX, Equinix Ashburn
TATA Communications formerly VSNL is Leading ISPAS4755AMS-IX
Rogers Communications Canada Inc.AS812Equinix Ashburn, Equinix Chicago
TELUS Communications Inc.AS852Equinix Chicago
KDDI CORPORATIONAS2516Equinix Palo Alto
Internet Initiative Japan Inc.AS2497Equinix Ashburn, Equinix Palo Alto, Equinix Singapore
Telefonica International Wholesale Services II, S.L.U.AS12956AMS-IX, Equinix Ashburn

@ayounsi is there an existing process for this?

Current process is to lookup their email contact in PeeringDB and manually send them an email, CCing our peering@ email.

So I should do that for that list? Are you ok with me requesting peering from all of these AS?

Is there an existing email template?

So I should do that for that list? Are you ok with me requesting peering from all of these AS?

Is there an existing email template?

No, please don't :)

Some of that data is not really accurate, some of it there are good business reasons not to, some of those we know are not going to do it, and some of these we've tried in the past and failed. (I'm afraid I can't be more specific than that on a public task). @ayounsi can curate the list and reach out to the ones that we could conceivably peer with (spoiler alert: a probably /very/ small list, if there are any at all)

I took a look at that list above. It's really not very actionable -- most of these are very large networks that have a restrictive settlement-free peering policy. For the few that remain, we have either established peerings already or have sent unanswered peering requests, which mostly means that they are not actively peering or we are too small for them to care about.