Presentation on theme: "Re-Thinking Internet Architecture"— Presentation transcript:
1Re-Thinking Internet Architecture Today’s InternetOriginal Design Goal, Philosophy and PrinciplesEnd-to-End Principle and “Hourglass” Architecture of InternetPros and Cons; Challenging IssuesWhat have changed? What may have yet to come?Overlay NetworksFuture Internet Architectures?What are key challenges/issues?E.g., mobility, security, “services-oriented” …Diversity of “end systems”: laptops, cell phones, sensors, …
2Network Architecture What is (Network) Architecture? not the implementation itself“design blueprint” on how to “organize” implementationswhat interfaces are supportedwhere functionality is implementedTwo Basic Architectural PrinciplesModularity (e.g., layering)how to break network functionality into modulesEnd-to-End Argumentwhere to implement functionality
3Architectural Principles (not unique to networks!) Zhi-Li’s version (synthesized from various sources)End-to-end argumentfunctionality placementModularityIncrease inter-operability and manage complexityvertical partition -> layered architecturehorizontal partition?Keep it simple, stupid (KISS principle)Occam’s Razor: choose simplest among many solutions!complicated design increases system coupling (inter-dependence), amplifies errors, ..don’t over-optimize!Separating policies from mechanismsdecouple control from data“semantics-free”Design for scalehierarchy, aggregation, …
4Some Design/Implementation Principles virtualizationindirectionsoft state vs. hard statefate sharingrandomizationexpose faults, don’t suppress/ignorecaching……
5Original Internet Design Goals [Clark’88] In order of importance:Connect existing networksinitially ARPANET and ARPA packet radio networkSurvivabilityensure communication service even with network and router failuresSupport multiple types of servicesMust accommodate a variety of networksAllow distributed managementAllow host attachment with a low level of effortBe cost effectiveAllow resource accountability
6PrioritiesThe effects of the order of items in that list are still felt todayE.g., resource accounting is a hard, current research topicDifferent ordering of priorities would make a different architecture!How well has today’s Internet satisfied these goals?Let’s look at them in detail
7Summary: Internet Architecture TCPUDPPacket-switched datagram networkIP is the “compatibility layer”Hourglass architectureAll hosts and routers run IPStateless architectureNo per flow state inside networkIPSatelliteEthernetATM
8Summary: Minimalist Approach Dumb networkIP provide minimal functionalities to support connectivityAddressing, forwarding, routingSmart end systemTransport layer or application performs more sophisticated functionalitiesFlow control, error control, congestion controlAdvantagesAccommodate heterogeneous technologies (Ethernet, modem, satellite, wireless)Support diverse applications (telnet, ftp, Web, X windows)Decentralized network administrationBeginning to show ageUnclear what the solution will be probably IPv6?
9Questions What priority order would a commercial design have? What would a commercially invented Internet look like?What goals are missing from this list?Which goals led to the success of the Internet?
10Requirements for Today’s Internet Some key requirements (“-ities”)Availability and reliability“Always on”, fault-tolerant, fast recovery from failures, …Quality-of-service (QoS) for applicationsfast response time, adequate quality for VoIP, IPTV, etc.Scalabilitymillions or more of users, devices, …Mobilityuntethered access, mobile users, devices, …Security (and Privacy?)protect against malicious attacks, accountability of user actions?Manageabilityconfigure, operate and manage networkstrouble-shooting network problemsFlexibility, Extensibility, Evolvability, ……?ease of new service creation and deployment?evolvable to meet future needs?
11End System Based Overlay/P2P Services/Solutions General Concept of OverlaysSome ExamplesEnd-System MulticastRationaleHow to construct “self-organizing” overlayPerformance in support conferencing applicationsInternet Indirection Infrastructure (i3)Motivation and Basic ideasImplementation OverviewApplications
14Overlay Networks A logical network built on top of a physical network Overlay links are tunnels through the underlying networkMany logical networks may coexist at onceOver the same underlying networkAnd providing its own particular serviceNodes are often end hostsActing as intermediate nodes that forward trafficProviding a service, such as access to filesWho controls the nodes providing service?The party providing the service (e.g., Akamai)Distributed collection of end users (e.g., peer-to-peer)
15Routing Overlays Alternative routing strategies No application-level processing at the overlay nodesPacket-delivery service with new routing strategiesIncremental enhancements to IPIPv6MulticastMobilitySecurityRevisiting where a function belongsEnd-system multicast: multicast distribution by end hostsCustomized path selectionResilient Overlay Networks: robust packet delivery
16IP Tunneling IP tunnel is a virtual point-to-point link Illusion of a direct link between two separated nodesEncapsulation of the packet inside an IP datagramNode B sends a packet to node E… containing another packet as the payloadABEFLogical view:tunnelABEFPhysical view:
18MBone: IP Multicast Multicast IP multicast Delivering the same data to many receiversAvoiding sending the same data many timesIP multicastSpecial addressing, forwarding, and routing schemesNot widely deployed, so MBone tunneled between nodesunicastmulticast
19End-System Multicast IP multicast still is not widely deployed Technical and business challengesShould multicast be a network-layer service?Multicast tree of end hostsAllow end hosts to form their own multicast treeHosts receiving the data help forward to others
20RON: Resilient Overlay Networks Premise: by building application overlay network, can increase performance and reliability of routingapplication-layerrouterPrincetonYaleBerkeleyTwo-hop (application-level)Berkeley-to-Princeton route
21RON Can Outperform IP Routing IP routing does not adapt to congestionBut RON can reroute when the direct path is congestedIP routing is sometimes slow to convergeBut RON can quickly direct traffic through intermediaryIP routing depends on AS routing policiesBut RON may pick paths that circumvent policiesThen again, RON has its own overheadsPackets go in and out at intermediate nodesPerformance degradation, load on hosts, and financial costProbing overhead to monitor the virtual linksLimits RON to deployments with a small number of nodes
22Secure Communication Over Insecure Links Encrypt packets at entry and decrypt at exitEavesdropper cannot snoop the data… or determine the real source and destination
23Communicating With Mobile Users A mobile user changes locations frequentlySo, the IP address of the machine changes oftenThe user wants applications to continue runningSo, the change in IP address needs to be hiddenSolution: fixed gateway forwards packetsGateway has a fixed IP address… and keeps track of the mobile’s address changesgateway
24Unicast Emulation of Multicast End SystemsRoutersGatechCMUStanfordBerkeley
25Routers with multicast support IP MulticastGatechStanfordCMUBerkeleyRouters with multicast supportNo duplicate packetsHighly efficient bandwidth usageKey Architectural Decision: Add support for multicast in IP layer
26Key Concerns with IP Multicast Scalability with number of groupsRouters maintain per-group stateAnalogous to per-flow state for QoS guaranteesAggregation of multicast addresses is complicatedSupporting higher level functionality is difficultIP Multicast: best-effort multi-point delivery serviceEnd systems responsible for handling higher level functionalityReliability and congestion control for IP Multicast complicatedDeployment is difficult and slowISP’s reluctant to turn on IP Multicast
27End System Multicast Overlay Tree Gatech Stan1 Stanford Stan2 Berk1 CMUGatechStan1StanfordStan2Berk1CMUStan1Stan2Berk2Overlay TreeGatechBerk1Berkeley
28Potential Benefits Scalability Easier to deploy Routers do not maintain per-group stateEnd systems do, but they participate in very few groupsEasier to deployPotentially simplifies support for higher level functionalityLeverage computation and storage of end systemsFor example, for buffering packets, transcoding, ACK aggregationLeverage solutions for unicast congestion control and reliability
29Design Questions Is End System Multicast Feasible? Target applications with small and sparse groupsHow to Build Efficient Application-Layer Multicast “Tree” or Overlay Network?Narada: A distributed protocol for constructing efficient overlay trees among end systemsSimulation and Internet evaluation results to demonstrate that Narada can achieve good performance
30Performance Concerns Delay from CMU to Berk1 increases Gatech Stan1Stan2Berk2GatechBerk1Delay from CMU toBerk1 increasesCMUGatechStan1Stan2Berk1Berk2Duplicate Packets:Bandwidth Wastage
31What is an efficient overlay tree? The delay between the source and receivers is smallIdeally,The number of redundant packets on any physical link is lowHeuristic used:Every member in the tree has a small degreeDegree chosen to reflect bandwidth of connection to InternetCMUCMUCMUStan2Stan2Stan2Stan1Stan1Stan1Berk1GatechBerk1GatechBerk1GatechBerk2Berk2Berk2High latencyHigh degree (unicast)“Efficient” overlay
32Why is self-organization hard? Dynamic changes in group membershipMembers may join and leave dynamicallyMembers may dieLimited knowledge of network conditionsMembers do not know delay to each other when they joinMembers probe each other to learn network related informationOverlay must self-improve as more information availableDynamic changes in network conditionsDelay between members may vary over time due to congestion
33Performance Metrics Delay between members using Narada Stress, defined as the number of identical copies of a packet that traverse a physical linkBerk2CMUStan1Stan2GatechBerk1Delay from CMU toBerk1 increasesStan1Stress = 2CMUStan2Berk1GatechBerk2
34ESM ConclusionsProposed in 1989, IP Multicast is not yet widely deployedPer-group state, control state complexity and scaling concernsDifficult to support higher layer functionalityDifficult to deploy, and get ISP’s to turn on IP MulticastIs IP the right layer for supporting multicast functionality?For small-sized groups, an end-system overlay approachis feasiblehas a low performance penalty compared to IP Multicasthas the potential to simplify support for higher layer functionalityallows for application-specific customizations
35Internet Indirection Infrastructure (i3) MotivationsToday’s Internet is built around a unicast point-to-point communication abstraction:Send packet “p” from host “A” to host “B”This abstraction allows Internet to be highly scalable and efficient, but…… not appropriate for applications that require other communications primitives:MulticastAnycastMobility…Today’s internet is build around a point-to-point communication abstractions.While this simple abstraction allows Internet to be highly scalable andEfficient, it is not appropriate for application that requires other communication primitives such as multicast, anycast, mobility, and so on.
36Why?Point-to-point communication implicitly assumes there is one sender and one receiver, and that they are placed at fixed and well-known locationsE.g., a host identified by the IP address xxx.xxx is located in BerkeleyThis is because there is a fundamental mismatch between point-to-point communication abstraction and these primitives.In particulr, the point-to-point communication abstraction implicitly assumes that there is only one sender and on receivers an that they are placed at fixed and well-known locations. Multicast, anycast, and mobility violate at least one of these assumptions. With mobility end-hosts do not have fixed locations, with multicast there are more than one receiver and sender.
37IP Solutions Extend IP to support new communication primitives, e.g., Mobile IPIP multicastIP anycastDisadvantages:Difficult to implement while maintaining Internet’s scalability (e.g., multicast)Require community wide consensus -- hard to achieve in practiceDuring the last decade a plethora of solutions have been proposed to implement anycast, multicast, and mobility functionalities. These solutions can be classified into two catgeories: IP solutions and application level solutions.Example of IP solutions are mobile IP, IP multicast, and IP anycastUnfortunately, despite years of research these solutions have yet to be deployed on a large scale. There are many reasons for this. Two of them are
38Application Level Solutions Implement the required functionality at the application level, e.g.,Application level multicast (e.g., Narada, Overcast, Scattercast…)Application level mobilityDisadvantages:Efficiency hard to achieveRedundancy: each application implements the same functionality over and over againNo synergy: each application implements usually only one service; services hard to combineTo get around these problems recently several application level solutions have been proposed…However, they have several disadvantages. First, it is hard to achieve efficiency….That is, proposal for application level multicast don’t address mobility and vice-versa. Usually, a new abstraction require to deploy a new overlay.
39Key Observation “Any problem in computer science can Virtually all previous proposals use indirection, e.g.,Physical indirection point mobile IPLogical indirection point IP multicast“Any problem in computer science canbe solved by adding a layer of indirection”
40Build an efficient indirection layer i3 SolutionBuild an efficient indirection layeron top of IPUse an overlay network to implement this layerIncrementally deployable; don’t need to change IPIPTCP/UDPApplicationIndir.layer
41Internet Indirection Infrastructure (i3): Basic Ideas Each packet is associated an identifier idTo receive a packet with identifier id, receiver R maintains a trigger (id, R) into the overlay networkiddataiddataSenderidRtriggerReceiver (R)Rdata
42Service Model API Best-effort service model (like IP) sendPacket(p);insertTrigger(t);removeTrigger(t) // optionalBest-effort service model (like IP)Triggers periodically refreshed by end-hostsID length: 256 bits
43MobilityHost just needs to update its trigger as it moves from one subnet to anotherReceiver(R1)SenderSuch an indirection layer would support a large number of services.For example, to achieve mobility an end host needs only to update its trigger with the new address when it moves from oneSubnet to another.idR2idR1Receiver(R2)
44Multicast Receivers insert triggers with same identifier Can dynamically switch between multicast and unicastiddataiddataR1dataidR1Receiver (R1)SenderMulticast is strightforward to achieve. The only difference between multicast and unicast is that in the case of the multicast there are more than on hosts inserting triggers with the same IDidR2R2dataReceiver (R2)
45Anycast Use longest prefix matching instead of exact matching Prefix p: anycast group identifierSuffix si: encode application semantics, e.g., locationSenderReceiver (R1)p|s1R1Receiver (R2)p|s2R2p|s3R3Receiver (R3)datap|a
46Service Composition: Sender Initiated Use a stack of IDs to encode sequence of operations to be performed on data pathAdvantagesDon’t need to configure pathLoad balancing and robustness easy to achieveTranscoder (T)idT,iddataidT,iddataiddataReceiver (R)RdataSenderT,iddataidRidTT
47Service Composition: Receiver Initiated Receiver can also specify the operations to be performed on dataFirewall (F)RdataiddataiddataF,RdataFinally, IL supports composable services, I.e., performing on the fly transformation such as transcoding on the data packets as they travel through the network.To achieve this we replace the packet ID with a stack of Ids, where each identifier excepting the last one identifies a transformation to be aplied on packets.The advantage of this solution versus previously proposed solutions is that you don’t need to find and configure the path,(you just insert the Ids in the proper order).Load balancing and robustness are easy to achieve. Just have more servers implementing the same operations. If one fails, the other one will take transparently over.Receiver (R)SenderidFFidF,RdataididF,R
48Quick Implementation Overview i3 is implemented on top of ChordBut can easily use CAN, Pastry, Tapestry, etcEach trigger t = (id, R) is stored on the node responsible for idUse Chord recursive routing to find best matching trigger for packet p = (id, data)
49Routing ExampleR inserts trigger t = (37, R); S sends packet p = (37, data)An end-host needs to know only one i3 node to use i3E.g., S knows node 3, R knows node 353720354137RStrigger(37,R)send(37, data)send(R, data)Chord circle2m-1[8..20][4..7][21..35][36..41][40..3]
50Optimization #1: Path Length Sender/receiver caches i3 node mapping a specific IDSubsequent packets are sent via one i3 node[8..20][4..7][42..3]37data[21..35]Sender (S)cache node[36..41]Rdata37RReceiver (R)
51Optimization #2: Triangular Routing Use well-known trigger for initial rendezvousExchange a pair of (private) triggers well-locatedUse private triggers to send data traffic[8..20][4..7]30data37[42..3]S2S[21..35]Sender (S)[36..41]Rdata2R30R37RReceiver (R)
52Example 1: Heterogeneous Multicast Sender not aware of transformationsReceiver R1(JPEG)id_MPEG/JPEGS_MPEG/JPEGid(id_MPEG/JPEG, R1)send(id, data)Sender(MPEG)send((id_MPEG/JPEG, R1), data)send(R1, data)R2Receiver R2send(R2, data)Finally, IL supports composable services, I.e., performing on the fly transformation such as transcoding on the data packets as they travel through the network.To achieve this we replace the packet ID with a stack of Ids, where each identifier excepting the last one identifies a transformation to be aplied on packets.The advantage of this solution versus previously proposed solutions is that you don’t need to find and configure the path,(you just insert the Ids in the proper order).Load balancing and robustness are easy to achieve. Just have more servers implementing the same operations. If one fails, the other one will take transparently over.
53Example 2: Scalable Multicast i3 doesn’t provide direct support for scalable multicastTriggers with same identifier are mapped onto the same i3 nodeSolution: have end-hosts build an hierarchy of trigger of bounded degreeR2R1R4R3gx(g, data)(x, data)
54Example 2: Scalable Multicast (Discussion) Unlike IP multicast, i3Implement only small scale replication allow infrastructure to remain simple, robust, and scalableGives end-hosts control on routing enable end-hosts toAchieve scalability, andOptimize tree construction to match their needs, e.g., delay, bandwidth
55Example 3: Load Balancing Servers insert triggers with IDs that have random suffixesClients send packets with IDs that have random suffixessend( ,data)S1AS1S2S2S3S3send( ,data)S4S4B
56Example 4: ProximitySuffixes of trigger and packet IDs encode the server and client locationsS2S3S1send( ,data)S2S3S1
57Outline Implementation Examples Security Applications Protection against DoS attacksRouting as a serviceService composition platform
58Applications: Protecting Against DoS Problem scenario: attacker floods the incoming link of the victimSolution: stop attacking traffic before it arrives at the incoming linkToday: call the ISP to stop the traffic, and hope for the best!Our approach: give end-host control on what packets to receiveEnable end-hosts to stop the attacks in the network
59Why End-Hosts (and not Network)? End-hosts can better react to an attackAware of semantics of traffic they receiveKnow what traffic they want to protectEnd-hosts may be in a better position to detect an attackFlash-crowd vs. DoS
60Some Useful DefensesWhite-listing: avoid receiving packets on arbitrary portsTraffic isolation:Contain the traffic of an application under attackProtect the traffic of established connectionsThrottling new connections: control the rate at which new connections are opened (per sender)
61IDP – public trigger IDS, IDR – private triggers 1. White-listingPackets not addressed to open ports are dropped in the networkCreate a public trigger for each port in the white listAllocate a private trigger for each new connectionIDSSSender (S)Receiver (R)[IDR]IDRRdataIDP[IDS]IDP – public trigger IDS, IDR – private triggers
622. Traffic IsolationDrop triggers being flooded without affecting other triggersProtect ongoing connections from new connection requestsProtect a service from an attack on another servicesVictim (V)Attacker(A)Legitimate client(C)ID2VID1Transaction serverWeb server
632. Traffic Isolation (cont’d) Drop triggers being flooded without affecting other triggersProtect ongoing connections from new connection requestsProtect a service from an attack on another servicesVictim (V)Attacker(A)Legitimate client(C)ID1VTransaction serverWeb serverTraffic of transaction serverprotected from attack on web server
643. Throttling New Connections Redirect new connection requests to a gatekeeperGatekeeper has more resources than victimCan be provided as a 3rd party serviceServer (S)Client (C)IDCCXSpuzzlepuzzle’s solutionGatekeeper (A)IDPA
65Service Composition Platform Goal: allow third-parties and end-hosts to easily insert new functionality on data pathE.g., firewalls, NATs, caching, transcoding, spam filtering, intrusion detection, etc..Why i3?Make middle-boxes part of the architectureAllow end-hosts/third-parties to explicitly route through middle-boxes
66ExampleUse Bro system to provide intrusion detection for end-hosts that desire soBro (middle-box)M(idM:idBA, data)(idBA, data)(idAB, data)(idM:idAB, data)idMMserver BidBABclient AidABAi3
67Design Principles Give hosts control on routing A trigger is like an entry in a routing table!Flexibility, customizationEnd-hosts canSource routeSet-up acyclic communication graphsRoute packets through desired service pointsStop flows in infrastructure…Implement data forwarding in infrastructureEfficiency, scalability
69ConclusionsIndirection – key technique to implement basic communication abstractionsMulticast, Anycast, Mobility, …I3Advocates for building an efficient Indirection Layer on top of IPExplore the implications of changing the communication abstraction; already done in other fieldsDirect addressable vs. associative memoriesPoint-to-point communication vs. Tuple space (in Distributed systems)
70Requirements for Today/Tomorrow’s Internet? Some key requirements (“-ities”)Availability and reliability“Always on”, fault-tolerant, fast recovery from failures, …Quality-of-service (QoS) for applicationsfast response time, adequate quality for VoIP, IPTV, etc.Scalabilitymillions or more of users, devices, …Mobilityuntethered access, mobile users, devices, …Security (and Privacy?)protect against malicious attacks, accountability of user actions?Manageabilityconfigure, operate and manage networkstrouble-shooting network problemsFlexibility, Extensibility, Evolvability, ……?ease of new service creation and deployment?evolvable to meet future needs?
71Key Issues, Challenges, Solutions … A More Network-Centric ViewNew Naming/Addressing?Separating “identifiers” and “locators” to better support mobility“semantic-free” flat id space ?Data centric?Role of “search” on naming, etc.Scalable and Robust RoutingBetter and more adaptive to failures, and other network eventsAlso better support for network management, security, …how to perform routing on “flat id” space?Or shall we decouple routing from “naming” or “addressing” ?Manageability“Centralized” approach…?Security (and Privacy?)More “accountable” networks, e.g., through “naming,” or id management?
72Key Issues, Challenges, Solutions … Applications and Technology are Dual Drivers !More devices are connected, novel technologies, disruptive new applications/servicesGoogle, and its impact of how we access Internet todaysocial networking: Facebook, MySpace, …iPod/iTune, Skype, BitTorrent, P2P video streaming, YouTube, Hulu.com, Kindle and Amazon, Ebay, …smart phones, etc., “third screen”“Cloud computing”, data centers, and “software as services”Flexibility, Evolvability, and Economic Viability of Network Architectures!It’s “service”, stupid!But is network a (shared) “utility”, “commodity”, or “service” ?“Networks” as services (e.g., VPNs), network security as services, …Network Virtualization and Virtualized Network ArchitecturesUser/application “customize-able” network services?Ultimately, networks should be “invisible” !