3 ms·

These presentations from Google are pretty irritating at these conferences. If you're familiar with the SDN field (as most ONS attendees would be), this present

by hueving 10y ago

These presentations from Google are pretty irritating at these conferences. If you're familiar with the SDN field (as most ONS attendees would be), this presentation is essentially nothing but bragging about the scale at which they operate. There is no useful information in here to advance the state of the art, no new ideas, no publicly available implementations (closed or open source). It's just a very high-level architectural view of a large network given by people who are incentivized to present it in the most favorable light. And due to the lack of any concrete details, it's free from critical analysis. >Espresso delivers two key pieces of innovation. First, it allows us to dynamically choose from where to serve individual users based on measurements of how end-to-end network connections are performing in real time. Second, we separate the logic and control of traffic management from the confines of individual router “boxes.” The first has been done before at many levels of the network: * BGP anycast * DNS responses based on querier * Done in load balancer * IGP protocols to handle traffic internally while taking into account link congestion I assume their framework gives them much nicer primitives to work with than the above, which would be an advancement in the field if we could actually see an API or something. The second is very far from "innovation". This is the essence of SDN and this has been the hottest thing since sliced bread in the networking world since 2008 at a minimum [1] and even earlier if you look at things like the Aruba wireless controller. 1. http://archive.openflow.org/documents/openflow-wp-latest.pdf http://archive.openflow.org/documents/openflow-wp-latest.pdf

runeks 10y ago
I very much agree. I was hoping Espresso would be a framework for allowing GCP user applications to leverage Google's SDN, rather than just allow Google to offer their own services using this technology. I hope that's the next step. For example, it would be cool if it were possible to move shared-client/server-secret checking (eg. for an HTTP API) out to the edge of Google's network, such that a DDoS attack with invalid packets (secrets) never even reach the application VM/cluster. DDoS attacks, which force applications offline (by making the app scale up to an unsustainable cost level), could be prevented this way.
- cobookman 10y ago
  You can do that by using Google clouds https load balancer.
lobster_johnson 10y ago
I don't disagree, but they have published a lot of papers about their networking research and implementation of things like like B4 and their SDN work [1]. Hopefully there's a paper on Espresso forthcoming, although the absence (as far as I can tell) of a paper on Andromeda alone means it might not be. [1] https://research.google.com/pubs/Networking.html https://research.google.com/pubs/Networking.html
Terretta 10y ago
Yes. The term "innovation" applied to the two ideas bugged me too. Could be a 'smart people problem' -- easier to 'innovate' a new wheel then visualize how existing tools can be remixed to solve. For an example of remixing, it was apparent 15 years ago that traditional routing was actively harmful for live and VOD video streaming, so we cobbled a mix of the techniques you listed plus a couple more[1] to connect users to edges in real time based on actual real-time end-to-end conditions. We did it consciously using these two ideas, plus content aware caching, plus one more "magic" but super trivial idea I still haven't seen elsewhere in the wild. The low tech rethink worked well, handily outperformed proprietary solutions per industry perf and SLO metrics companies, and it's been an ongoing surprise me that it's taken so long for others to rethink or remix the same way. We filed no patents, as to your point, this all could be argued evident to anyone 'skilled in the art'. --- 1. A couple custom bits: we also had to write an edge server shim as no media server at the time could handle sessions flapping in real time, not to mention the content awareness crucial for giant media files.
collinmanderson 10y ago
I don't know much about SDN, but Google did seem to imply that DNS responses based on querier is not a very good solution. > Rather than pick a static point to connect users simply based on their IP address (or worse, the IP address of their DNS resolver), we dynamically choose the best point and rebalance our traffic based on actual performance data. Similarly, we are able to react in real-time to failures and congestion both within our network and in the public Internet.

by hueving 10y ago

runeks 10y ago

I very much agree. I was hoping Espresso would be a framework for allowing GCP user applications to leverage Google's SDN, rather than just allow Google to offer their own services using this technology. I hope that's the next step. For example, it would be cool if it were possible to move shared-client/server-secret checking (eg. for an HTTP API) out to the edge of Google's network, such that a DDoS attack with invalid packets (secrets) never even reach the application VM/cluster. DDoS attacks, which force applications offline (by making the app scale up to an unsustainable cost level), could be prevented this way.

cobookman 10y ago
You can do that by using Google clouds https load balancer.

lobster_johnson 10y ago

I don't disagree, but they have published a lot of papers about their networking research and implementation of things like like B4 and their SDN work [1]. Hopefully there's a paper on Espresso forthcoming, although the absence (as far as I can tell) of a paper on Andromeda alone means it might not be. [1] https://research.google.com/pubs/Networking.html https://research.google.com/pubs/Networking.html

Terretta 10y ago

Yes. The term "innovation" applied to the two ideas bugged me too. Could be a 'smart people problem' -- easier to 'innovate' a new wheel then visualize how existing tools can be remixed to solve. For an example of remixing, it was apparent 15 years ago that traditional routing was actively harmful for live and VOD video streaming, so we cobbled a mix of the techniques you listed plus a couple more[1] to connect users to edges in real time based on actual real-time end-to-end conditions. We did it consciously using these two ideas, plus content aware caching, plus one more "magic" but super trivial idea I still haven't seen elsewhere in the wild. The low tech rethink worked well, handily outperformed proprietary solutions per industry perf and SLO metrics companies, and it's been an ongoing surprise me that it's taken so long for others to rethink or remix the same way. We filed no patents, as to your point, this all could be argued evident to anyone 'skilled in the art'. --- 1. A couple custom bits: we also had to write an edge server shim as no media server at the time could handle sessions flapping in real time, not to mention the content awareness crucial for giant media files.

collinmanderson 10y ago

I don't know much about SDN, but Google did seem to imply that DNS responses based on querier is not a very good solution. > Rather than pick a static point to connect users simply based on their IP address (or worse, the IP address of their DNS resolver), we dynamically choose the best point and rebalance our traffic based on actual performance data. Similarly, we are able to react in real-time to failures and congestion both within our network and in the public Internet.