The paper is at: [pdf]
Problem statement: Egeress traffic to Google internet peers: They envision High Definition video delivery and cloud traffic. Two objectives: 1. Optimize traffic per-customer and per-application(optimal video quality and differentiated cloud service). 2. Deliver new features quickly.
They counter two criticisms of SDN: 1. Interoperability at Internet scale, 2. Cost reductions. Through large scale deployments, they show it is possible to incrementally evolve while maintaining interoperability. They also show that the value of SDN comes from the capability and its software feature velocity, with any cost savings being secondary.
Espresso: SDN based. previously B4 and jupiter.
Google has Global PoPs > 100.
Design principles: 1. Hierarchical control plane (global optimization), 2. Fail static (local control plane), 3. Software programmability (externalize features into software to exploit commodity servers for scale). 4. Testability 5. Manageability.
Architecture:
Traditional: Peering router - internalize routing/forwarding-large ACL - external peer
Espresso: BGP speaker and label-switched fabric are introduced in software, basically Externalize BGP and packet processing.
Host based packet processor allows flexible packet processing, including ACL and handling of DoS.
Application aware routing: application will send signals to global controller.
Using user's best path, not BGP's: serve 13% more traffic than BGP's best path.
Q & A:
1. How you picked three ISP? Are all the ISPs works in same way?
2. How we actually know the client traffic? While measuring small amount of traffic its fine. But if you measure huge amount of traffic,you might overload other parts of framework. How do you handle this?
3. Is information from controller is enough? what all applications you can optimize?
This comment has been removed by the author.
ReplyDelete