Internet History, Architecture, and Routing

1. Internet History, Architecture, and Routing ECON 425/563 & CPSC 455/555 9/25/2008 ECON 425/563 & CPSC 455/555 9/25/2008

2. Internet History • Late 1960s and early 1970s: ARPANET • US Department of Defense • Connects small ARPA-sponsored data networks • Ground breaking testbed for network ideas and designs • Early 1980s: Other wide-area data networks are established (e.g., BITNET and Usenet). • Late 1980s and early 1990s: • “ARPANET” fades out. • US Gov’t sponsors NSFNET, which connects large regional networks. • Commercial data networks become popular (e.g., Prodigy, Compuserve, and AOL). • Mid-1990s: Unified “Internet”

3. Internet Protocols Design Philosophy • Ordered set of goals: 1. multiplexed utilization of existing networks 2. survivability in the face of failure 3. support multiple types of communications service 4. accommodate a variety of network types 5. permit distributed management of resources 6. cost effective 7. low effort to attach a host 8. account for resources • Not all goals have been met

4. Packets! • Basic decision: use packets not circuits (Kleinrock) • Packet (a.k.a. datagram) • self contained • handled independently of preceding or following packets • contains destination and source internetwork address • may contain processing hints (e.g., QoS tag) • no delivery guarantees • net may drop, duplicate, or deliver out of order • reliability (where needed) done at higher levels Dest Addr Src Addr payload

5. Telephone Network • Connection-based • Admission control • Intelligence is“in the network” • Traffic carried by relatively few, “well-known” communications companies Internet • Packet-based • Best effort • Intelligence is“at the endpoints” • Traffic carried by many routers, operated by a changing set of “unknown” parties

6. Directly Connected Machines (a) (b) • (a) Point-to-point: e.g., ATM • (b) Multiple-access: e.g., Ethernet • Can’t build a network by requiring all nodes to be directly connected to each other; need scalability with respect to the number of wires or the number of nodes that can attach to a shared medium

7. Switched Network • Circuit switching vs. packet routing • Hosts vs. “the network,” which is madeof routers • Nice property: scalable aggregate throughput routers hosts

8. Interconnection of Networks Recursively build larger networks hosts gateway

9. Some Hard Questions hosts • How do hosts share links? • How do you name and address hosts? • Routing: Given a destination address,how do you get to it? gateway

10. IP Addresses andHost Names • Each machine is addressed by an integer, itsIP address, written down in a “dot notation” for “ease” of reading, such as 128.36.229.231 • IP addresses are the universal IDs that are used to name everything. • For convenience, each host also has ahuman-friendly host name. For example, 128.36.229.231 was concave.cs.yale.edu. • Question: How do you translate names intoIP addresses?

11. Domain Hierarchy • Initially, name-to-address mappingwas a flat file mailed out to all the machines on the Internet. • Now, we have a hierarchicalname space, just like a UNIXfile-system tree. • Top-level names (historical influence): heavily US-centric, government-centric, and military-centric viewof the world edu com gov mil org net uk fr Yale MIT Cisco . . . Yahoo Math CS Physics concave cyndra netra

12. DNS Zones andName Servers • Divide up the name hierarchy into zones. • Each zone corresponds to one or more name servers under the same administrative control. edu com gov mil org net uk fr Yale MIT Cisco . . . Yahoo Math CS Physics concave cyndra netra

13. Hierarchy of Name Servers Root name server • Clients send queries to name servers. • Name servers reply with answers or forward requests to other name servers. • Most name servers perform “lookup caching.” Yale name server Cisco name server . . . CS name server EE name server

14. Application-Level Abstraction host application host • What you have: hop-to-hop links, multiple routes, packets, can be potentially lost, can be potentially delivered out-of-order • What you may want: application-to-application (end-to-end) channel, communication stream, reliable, in-order delivery host application host host

15. Basic Architectural Principle: Layering Simple NetworkManagement HTTP (Web) Domain Name Service Telnet Transmission Control Protocol User Datagram Protocol Internet Protocol Ethernet SONET ATM

16. Verizon AT&T Comcast Qwest Interdomain Routing Establish routes between autonomous systems (ASes). Currently done with the Border Gateway Protocol (BGP).

17. Why is Interdomain Routing Hard? • Route choices are based on local policies. • Autonomy: Policies are uncoordinated. • Expressiveness: Policies are complex. Always chooseshortest paths. Load-balance myoutgoing traffic. Verizon AT&T Comcast Qwest Avoid routes through AT&T ifat all possible. My link to UUNET is forbackup purposes only.

18. BGP Route Processing (1) • The computation of a single node repeats the following: Choose“Best”Route UpdateRouting Table Send updatesto neighbors Receive routes from neighbors • Paths go through neighbors’ choices, which enforces consistency. • Decisions are made locally, which preserves autonomy. • Uncoordinated policies can induce protocol oscillations. (Much recent work addresses BGP convergence.) • Recently, private information, optimization, and incentive-compatibility have also been studied.

19. BGP Route Processing (2) IP Forwarding Table Install forwarding entries for best routes Apply Import Policies Routing Table Best Route Selection Apply Export Policies Apply Policy = filter routes & tweak attributes Apply Policy = filter routes & tweak attributes Based on attribute values Transmit BGP updates Receive BGP updates Storageof routes Open-ended programming: constrained only by vendor configuration language

20. Example: Convergence Prefer direct route to d 2 1 Prefer routes through 2 d

21. Example: Oscillation Prefer routes through 1 BGP might oscillateforever between 1d, 2d and 12d, 21d 2 1 Prefer routes through 2 d

22. Example: Convergence Prefer routes through 1 2 1 Prefer routes through 2 d

23. Dispute Wheels Nodes ui, hub routes Ri, and spoke routes Qi. Each ui prefers RiQi+1 to Qi. “No dispute wheel” —> robust convergence

24. Gao-Rexford Framework (1) Neighboring pairs of ASes have one of: • a customer-provider relationship(One node is purchasing connectivity fromthe other node.) • a peering relationship(Nodes have offered to carry each other’stransit traffic, often to shortcut a longer route.) peer providers customers peer

25. Gao-Rexford Framework (2) • Global constraint: no customer-provider cycles • Local preference and scoping constraints, which are consistent with Internet economics: • Gao-Rexford conditions => BGP always converges [GR01] Preference Constraints Scoping Constraints . . . . R1 j provider k1 . . . . . . . . . . d . . . . i peer d i R2 . . . . . . m k2 k customer • If k1 and k2 are both customers, peers, or providers of i, then either ik1R1 orik2R2 can be more valued at i. • If one is a customer, prefer the route through it. If not, prefer the peer route. • Export customer routes to all neighbors and export all routes to customers. • Export peer and provider routes to all customers only.

26. Ongoing Research Challenge Fully characterize the conditions under which BGP converges (robustly). • “No dispute wheel” is sufficient but not necessary. Is it enforceable? • On those instances on which BGP is guaranteed to converge, how many rounds does it take to converge?