SDN for Reliable Process Protocol
•Télécharger en tant que PPTX, PDF•
0 j'aime•367 vues
SDN for Reliable Process Protocol a presentation by George Adams at the US Ignite ONF GENI workshop on October 8, 2013
Recommandé
Recommandé
Contenu connexe
Similaire à SDN for Reliable Process Protocol
Similaire à SDN for Reliable Process Protocol (20)
Plus de US-Ignite
Plus de US-Ignite (20)
Dernier
Dernier (20)
SDN for Reliable Process Protocol
- 1. SDN for Reliable Process Protocol George Adams1, Doug Comer1, Rajas Karandikar1, Bhaskar Sarma1, John Geske2, Alison Chan2, Judi Clark3, Pat Kennedy3, Jim Morrison3, and Ralf Muehlen4 1 Purdue University 2 Kettering University 3 Lit San Leandro 4 Internet Archive
- 2. We want to rely on great Apps that rely on great Internet communication
- 3. Internet communication Reliable Assured Real-time Throughput scales well with link speed
- 5. Delay search 500 ms = Revenue/user down 1.2%
- 6. Delay search 400 ms = Searching down 0.74%
- 7. What to do? Use software defined networking (SDN) to create, categorize, and manage multiple paths
- 8. Internet with multiple paths RC End System RC End System
- 9. Internet with multiple paths RC App RC App
- 10. Internet with multiple paths RC App RC App
- 11. Internet with multiple paths RC App RC App
- 12. RCs learn in real-time RC App RC App
- 13. Build replacement path with SDN RC End System RC End System
- 14. Multiple paths in the lab
- 15. Multiple paths in the lab
- 16. Multiple paths across the country
- 17. Reliable, assured, real-time Internet communication • Send multiple copies • Over different paths • Learn which paths to use • Built new paths as needed A fundamentally new Internet service
- 18. What should SDN do? • Support management of multiple paths with packet rate control of packet replication function and delivery to multiple network links • Support assessment of logical and physical path disjointness by reporting identity and geographic information for network hardware components • Generally, SDN should provide building blocks for fault tolerance at the speed of packet delivery
- 19. Protocol Team
- 20. Support
Notes de l'éditeur
- Hello, my name is George Adams and I lead the Mozilla Ignite team developing the Reliable Communication Protocol for Remote Process Control for applications in Advanced Manufacturing and many other areas.
- We want to rely on great Apps that RELY on great Internet communication.
- We want our voice and video calls to be high-fidelity, high definition, highly available, and to work flawlessly until WE are done.
- We want to reach out from wherever WE are to manufacture advanced parts anytime and anywhere.
- We want to control shared, advanced means of production without having to travel.We want to connect manufacturers so they can more easily form innovative supply chains.
- We want Apps that communicate life-critical information – vital signs and vital treatment directives -- while we are on the way to the hospital.
- And when we arrive, we can have remote expert consultation and mentoring available to the local doctor and, if needed, tele-robotic surgery performed by a highly experience practitioner. Bringing health care expertise to the front line.
- To achieve this we need Internet communication that is reliable, assured, and real-time.But is it these three things?We all know that the the answer is no, no, no !Furthermore, does the throughput we can achieve scale well with link speed?Also no.
- The Internet behaves this way because it is a one lane highway.Each packet follows a single path from sender to receiver.If any link along that path is congested or has failed, delivery of that packet is affected. The receiving App suffers and the sending App is unaware for a long time.Apps that depend critically on receiving all packets in a timely manner will not work or will be too risky.This situation is not only a problem for Apps of the Future.
- These technical issues have economic consequences, stormy weatherA study for Bing showed that a mere 500 ms delay in returning search results decreased revenue per user by 1.2%.
- A Google study published in 2009 showed that Inserting just 400 milliseconds of delay into Google search led after 4-6 weeks to users performing 0.74% fewer searches.And after that delay was removed, searching did not return to pre-study levels, even after another 4-6 weeks.Not so lucky.
- The answer is US Ignite, which is about gigabit broadband and also about software defined networking.
- We begin with two End Systems connected to the Internet represented as a collection of networks (yellow clouds) themselves connected to form the Internet and then with software defined networking we have Redundancy Controllers labeled RC connecting each End System to the Internet.
- Create and manage redundant paths with SDNRedundancy Controller (RC) sends 2 copies of each packetThe sending Redundancy Controller will send two copies of each packet of information.We now see an End System ready to send a packet, that is replicated, sent over the two paths, and merged at the receiving Redundancy Controller, which delivers the information to the receiving End System.
- Create and manage redundant paths with SDNRedundancy Controller (RC) sends 2 copies of each packetRemote RC monitors paths and delivers packetsBecause the receiving Redundancy Controller receives both copies of the packets under normal conditions, it can monitor the condition of each path.
- A network problem, shown by the red link, is detectable by delayed or failed arrival of packets on one path.
- Remote RC detects network problem (red link) because redundant packet is delayedRelays problem information to sending RC and SDN builds new pathThe Redundancy Controller can use this information to trigger construction of a new path, shown here in purple, restoring redundant paths, and maintaining reliable delivery of packets.FIT IN REDUCED LATENCY GRAPH AROUND HERE??????Transition: Now this is where it gets exciting.
- * What was an exciting moment in the development or end-user testing of the application? There were many moments of excitement. Our work started in the lab, and we were very pleased the first time we saw packets traveling along multiple paths. Then we used the National Science Foundation GENI platform for network experimentation to create multiple paths spanning the US. It was satisfying to see communication continue when one of the paths through the Internet became congested. However, the real excitement started when we could disable one of the paths and see our software select an alternative and when we controlled a 3D printer remotely and monitored the correctness of its behavior in detail with HD video.
- * What was an exciting moment in the development or end-user testing of the application? There were many moments of excitement. Our work started in the lab, and we were very pleased the first time we saw packets traveling along multiple paths. Then we used the National Science Foundation GENI platform for network experimentation to create multiple paths spanning the US. It was satisfying to see communication continue when one of the paths through the Internet became congested. However, the real excitement started when we could disable one of the paths and see our software select an alternative and when we controlled a 3D printer remotely and monitored the correctness of its behavior in detail with HD video.
- Multiple paths with SDN using National Science FoundationGlobal Environment for Network Innovations (GENI)
- Software-controlled manufacturing.
- This is our team
- This is our team
- The Mozilla Ignite challenge was the catalyst that caused me to act and to form a team, joining universities, a gigabit city, and industrial partners to build construct a practical and effective demonstration that spans the country.