Argo and the Cloudflare Global Private Backbone
blog.cloudflare.com
blog.cloudflare.com
If there's a particular part of the overall Argo that would be helpful for you or others, let us know and we'll certainly consider it. Here's a list of things we've built at Cloudflare and open sourced already: https://cloudflare.github.io/
- Tunnel (cloudflared): https://github.com/cloudflare/cloudflared
- Argo as ingress (k8s): https://github.com/cloudflare/cloudflare-ingress-controller/
Can Argo be enabled at network layer, say VPN, and for other protocols say VoIP and not just HTTP/S?
Does Argo take inspiration from published research? If so, which ones?
Thanks.
Re: enabling Argo at the network layer, watch this space :) I'd love to hear more about what you'd like to do such a product — email me! rustam@cloudflare.com
Additionally, we have found the Argo tunnel to be relatively unreliable. Once every few months it seems there is an issue with one of the PoPs, and it takes a long time before our tunnels reconnect (several hours even); which imho is fairly inexcusable for something as critical as this. As such we’ve had to migrate away from using the tunnel, leaving me with earlier mentioned questions on the value we’re getting.
Re: tunnel reliability, sorry to hear you've had a poor experience. We've been working hard on hardening things like tunnel reconnection and would love for you to give tunnels another shot.
Cheers, argo seems like an interesting project.
The data plane runs on our x86 fleet and its control plane is driven by custom route computation and propagation systems (discussed a little more in the post). We're excited to talk more about the technical underpinnings of Argo in the future.
Ha I was reading the post again thinking about how you all did this, and it boiled down to OpenFlow/OVS/SDN magic, or you REALLY went all in on Cisco offerings.
>We're excited to talk more about the technical underpinnings of Argo in the future.
Looking foward to this update, thanks for the response!
https://developers.cloudflare.com/argo-tunnel/trycloudflare/
> Here’s the same jitter chart between Chicago and Newark, except this time, transiting the Cloudflare Global Private Backbone... Here we see a jitter measurement of 536μs (microseconds), almost eight times better than the measurement over a transit provider between the same two sites.
This is really impressive. Will be interesting to see what's possible when network roundtrips are 2 orders of magnitude more stable.
Question to CF employees, since they usually participate here on HN: Any chance we are ever going to be able to enable Argo on specific domains / paths, similar to Workers?
1. We've started using our own backbone of fibre links to carry traffic.
2. The Argo product for route optimization and working around Internet problems.
#2 can take advantage of #1 now that it exists. #2 is a paid product.
>"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...
For a couple of my larger sites (PDF and Image heavy), I am unable to justify the Argo cost. On these sites, over half of my monthly traffic is to bots (Googlebot, Bingbot, Yandex, etc). Traffic costs make up of around half of my hosting bill. A couple of things are keeping me from transitioning these sites to Argo: - I'd rather pay to speed up only real-users (not bots) - I'd rather not pay for traffic not routed over Argo (currently all traffic gets billed under Argo for enabled domains, not just the smart-routed traffic)
I currently pay the following rates from Google Cloud->CloudFlare (depending on the CF datacenter the data gets routed to). NA: $0.04/GB EU: $0.05/GB APAC: $0.06/GB
If I could pay a similar rate for a speedup (for only the Argo-routed traffic), I'd be more likely to sign up for Argo on all of my domains.
From my experience, features are added to the Enterprise offerings, and then eventually brought down to lower plan levels. However, most things are based on usage now, not plan level and I expect that is a better path to monetization for CF compared to simply raising prices.