INTERNET EVOLUTION AND THE ROLE OF SOFTWARE ENGINEERING Pamela Zave AT&T Laboratories—Research Florham Park, New Jersey, USA
INTERNET EVOLUTION AND THE ROLE OF SOFTWARE ENGINEERING: OUTLINE WHAT IS THE STATE OF THE A INTERNET, AND WHY SHOULD SOFTWARE ENGINEERS BE A CONCERNED? A A WHAT CAN SOFTWARE- A ENGINEERING RESEARCHERS DO ABOUT IT? A
STATE OF THE "CLASSIC" INTERNET ARCHITECTURE THE "CLASSIC" INTERNET THE REAL INTERNET ARCHITECTURE the classic architecture has been defined in terms of layers with made obsolete by explosive growth in different functions users, traffic, and applications applications it does not meet current or future needs for . . . middleware . . . convergence of data, telephone, transport (TCP,UDP) Internet and broadcast networks, core network (IP) . . . security and reliability, link . . . quality of service, physical . . . resource management, designed to empower users and . . . balancing the interests of diverse encourage innovation stakeholders has succeeded beyond anyone's the good properties of the classic wildest dreams architecture are eroded badly by workarounds
THE STATE OF INTERNET APPLICATIONS THE INTERNET IS NOT THE COSTS AND BENEFITS OF NETWORK APPLICATION-FRIENDLY SECURITY Network-level security is provided by Network many application needs are Address Translation (NAT) and firewalls. not supported (mobility, multihoming, anycast, public Internet private subnet security, privacy, etc. ) machines here have no initiation of because there is little no persistent public communication, separation of concerns, . . . addresses even if wanted . . . mechanisms to solve problems are limited in yet applications are not secure! applicability and tend to break each other this form of security is inappropriate for peer-to-peer applications, making them difficult to build and very inefficient as a result, . . . NAT and firewalls are so tightly inter- . . . networked applications twined with TCP and UDP that unless they and middleware are complex, know about an application, it is unlikely to unreliable, . . . work i.e., unless it looks . . . and far too difficult to like a Web service build, deploy, and maintain
THE ST THE STATE OF INTERNET EVOLUTION TE OF INTERNET EVOLUTION [Handley 06] INTERNET "OSSIFICATION" there has been no important there has been no important change in the transport layer (TCP/ change in the network layer (IP) UDP) since 1988 since 1993 " . . . technologies get deployed in the core of the Internet when they solve an immediate problem or when money can be made" it is very difficult for an Internet a crisis is the only way to get the service provider to make money global consensus required for with improvements, because most real change have no effect until everyone else adopts them
THE STATE OF THE IETF . . . AS CAPTURED BY THE SPECIFICATION OF SIP THE MEDIUM THE MESSAGE IETF philosopy is to standardize the base document (IETF RFC 3261) based on "rough consensus and is 268 pages working code" it is continually being extended, finite-state machines are rarely bottom-up, in response to an used endless series of new use cases specifications are written in "A Hitchhiker's Guide to SIP" is a English, augmented only by snapshot of SIP RFCs and drafts . . . message sequence charts that look . . . which lists 142 documents, like this (IETF macros): totaling many thousands of process1 process2 pages opinions are based on two false assumptions: more generality can only be obtained with more complexity note how this forces you a bad scenario can be ignored if to forget race conditions! you claim it is rare (a "corner case") it is now so difficult to build SIP applications that there is talk of abandoning it
THE ST THE STATE OF NETWORKING RESEARCH TE OF NETWORKING RESEARCH [Rexford 10] "In my college networking class I fell asleep at the start of the semester when the IP header was on the screen, and woke up at the end of the semester with the TCP header on the screen."
THE ST THE STATE OF NETWORKING RESEARCH TE OF NETWORKING RESEARCH [Rexford 10] "In my college networking class I fell asleep at the start of the semester when the IP header was on the screen, and woke up at the end of the semester with the TCP header on the screen." "Networking is all details and no principles."
THE ST THE STATE OF NETWORKING RESEARCH TE OF NETWORKING RESEARCH [Rexford 10] "In my college networking class I fell asleep at the start of the semester when the IP header was on the screen, and woke up at the end of the semester with the TCP header on the screen." "Networking is all details and no principles." "There is a tendency in our field to believe that everything we currently use is a paragon of engineering, rather than a snapshot of our understanding at the time. We build great myths of spin about how what we have done is the only way to do it . . . to the point that our universities now teach the flaws to students . . . who don't know better." —John Day
THE ST THE STATE OF NETWORKING RESEARCH TE OF NETWORKING RESEARCH [Rexford 10] "In my college networking class I fell asleep at the start of the semester when the IP header was on the screen, and woke up at the end of the semester with the TCP header on the screen." "Networking is all details and no principles." "There is a tendency in our field to believe that everything we currently use is a paragon of engineering, rather than a snapshot of our understanding at the time. We build great myths of spin about how what we have done is the only way to do it . . . to the point that our universities now teach the flaws to students . . . who don't know better." —John Day "So, these network research people today aren't doing theory, and yet they aren't the people who brought us the Internet. What exactly are they doing?"
INTERNET EVOLUTION AND THE ROLE OF SOFTWARE ENGINEERING: OUTLINE WHAT IS THE STATE OF THE The Internet is not application-friendly. A INTERNET, AND WHY SHOULD Every segment of society has a stake in SOFTWARE ENGINEERS BE the Internet, . . . A CONCERNED? [Clark et al. 05] A . . . and this limits its usefulness to all of A them. A Businesses, networking researchers, and the IETF are not making progress toward A an application-friendly Internet, . . . . . . so software researchers have to do it. WHAT CAN SOFTWARE- ENGINEERING RESEARCHERS DO ABOUT IT?
EVOLUTION THROUGH OVERLAYS AND VIRTUALIZATION Common definition: An overlay is a custom-built network layer deployed over existing layers. OVERLAYS ARE THE MODULES OF AN OVERLAY IS A "CLEAN SLATE" NETWORK ARCHITECTURE FOR DESIGN FOR TODAY: FOR THE FUTURE: can experiment with new architectural ideas applications frequently used applications applications OVERLAYS to support applications OVERLAYS OVERLAYS better than the Internet core unvarnished (network, transport slice of slice of Internet does layers) resources resources ( e.g., Akamai, VPNs, some OVERLAYS virtualization middleware) network resources network resources (physical, link layers) in the end, there may be no universal Internet layer [Roscoe 2006]
BRIDGING THE KNOWLEDGE GAP BETWEEN SOFTWARE ENGINEERING + DISTRIBUTED SYSTEMS NETWORKING Using Day’s definition The definition makes clear of an overlay [Day 08], how overlays compose A each overlay contains in a hierarchy and all the basic mechanisms what their A of networking, relationships are. including naming, A communication service, security, A It is precise enough and resource to be formalized. management. A A The definition is a template that can be THIS IS THE TOOL I HAVE BEEN LOOKING FOR! instantiated differently for different purposes, deeply rooted in the history and practice of scopes, and levels. networking represents all the important concepts without unnecessary detail draws the module boundary in exactly the right place
DAY'S DEFINITION OF AN OVERLAY Registration: user processes in a higher overlay Communication Service: can register their locations at the overlay provides a member processes on the specified service for its users, E B same machine; there is a e.g., point-to-point sessions directory of registrations session( B,E ) Membership: the members are processes; each has a B unique and persistent C A E name from the name D space; enrollment protocol accepts and names new members Links: Routing: there is a link between any member can reach any two member processes other through a path in the if both are registered THERE IS overlay; routing protocol in the same lower SECURITY AND spreads knowledge of links overlay RESOURCE and paths; forwarding protocol MANAGEMENT uses path knowledge THROUGHOUT
THE SESSION INTERFACE BETWEEN OVERLAYS UPPER OVERLAY session A B request- accept- session Session(A,B,sa) Session(A,B,sb) API calls send(sa,msg) send(sb,msg) receive(sa,msg) receive(sb,msg) LOWER OVERLAY a b path of session routing and forwarding can cause congestion and loss (as in IP), . . . initially a receives request, looks up location of B at b, caches b, . . . so the overlay also needs flow and sends request from a to b and error control (as in TCP)
Recommend
More recommend
