Re:Argo and the Cloudflare Global Private Backbone
by bogomipz on Monday May 13, 2019 @03:44PM
(#19903169)
This looks like little more than marketing fluff and with rather confusing messaging at that. For example the post states:
>"One specific example of Argo’s smarts is its ability to distinguish between multiple potential connectivity options as it leaves a given data center. We call this “transit selection”
A "global private backbone" and edge routing have zero to do with each other. They are orthogonal. You can "pref" your transit provider's customer routes from just within POP itself. This has zero to do with whether or not you have a "backbone." The way this works is that you pick your top N destination ASNs and continuously monitor ping time, jitter packet loss etc. Then you prefer the more desirable routes via iBGP. This is not new and not innovative either. Internap has been this 20 for years now. This was the whole "secret sauce" of their PNAP architecture back in the day. In fact they even sold a hardware device to do it called the Internap FCP(flow control platform)it has since been named MIRO [1][2]. Of course many people do exactly this themselves with BIRD/Quagga/Exabgp and some Python. And you certainly don't need "machine learning" to do this.
As a CDN customer I only care about getting the best path from the POP back to the eyeball networks. Why would it matter whether the CDN provider has fiber between two of their POPs? There should be enough transit diversity at each edge location
that fiber between POPs is irrelevant. I should spend as little time on the CDN provider's network as possible i.e "hot potato" routing. This is the whole value proposition of a CDN. Honestly this whole sounds like a cost savings mechanism that they've trying to spin and sell as a product innovation.
Also where is the Cloudflare backbone map? It seems to be conspicuously absent for announcement about a "global private backbone." How many route miles are there? Is it an actual backbone or this just some CWDM gear that only connects POPs in the same city over municipal fiber?
>"One specific example of Argo’s smarts is its ability to distinguish between multiple potential connectivity options as it leaves a given data center. We call this “transit selection”
A "global private backbone" and edge routing have zero to do with each other. They are orthogonal. You can "pref" your transit provider's customer routes from just within POP itself. This has zero to do with whether or not you have a "backbone." The way this works is that you pick your top N destination ASNs and continuously monitor ping time, jitter packet loss etc. Then you prefer the more desirable routes via iBGP. This is not new and not innovative either. Internap has been this 20 for years now. This was the whole "secret sauce" of their PNAP architecture back in the day. In fact they even sold a hardware device to do it called the Internap FCP(flow control platform)it has since been named MIRO [1][2]. Of course many people do exactly this themselves with BIRD/Quagga/Exabgp and some Python. And you certainly don't need "machine learning" to do this.
As a CDN customer I only care about getting the best path from the POP back to the eyeball networks. Why would it matter whether the CDN provider has fiber between two of their POPs? There should be enough transit diversity at each edge location that fiber between POPs is irrelevant. I should spend as little time on the CDN provider's network as possible i.e "hot potato" routing. This is the whole value proposition of a CDN. Honestly this whole sounds like a cost savings mechanism that they've trying to spin and sell as a product innovation.
Also where is the Cloudflare backbone map? It seems to be conspicuously absent for announcement about a "global private backbone." How many route miles are there? Is it an actual backbone or this just some CWDM gear that only connects POPs in the same city over municipal fiber?
[1] https://www.inap.com/press-release/internap-rebuilds-patente...
[2] https://www.businesswire.com/news/home/20080206005468/en/Tel...