IP revisited

1. IP revisited Taekyoung Kwon tkkwon@snu.ac.kr Courtesy of Kevin Lai and Ion Stoica with Berkeley Jim Kurose with Umass Henning Schulzrinne with Columbia

2. network resources (e.g., bandwidth) divided into “pieces” pieces allocated to calls resource piece idle if not used by owning call (no sharing) dividing link bandwidth into “pieces” frequency division time division Network Core: Circuit Switching

3. each end-end data stream divided into packets user A, B packets share network resources each packet uses full link bandwidth resources used as needed, Bandwidth division into “pieces” Dedicated allocation Resource reservation Network Core: Packet Switching resource contention: • aggregate resource demand can exceed amount available • congestion: packets queue, wait for link use • store and forward: packets move one hop at a time • transmit over link • wait turn at next link

4. Packet-switching versus circuit switching: human restaurant analogy other human analogies? Network Core: Packet Switching 10 Mbs Ethernet C A statistical multiplexing 1.5 Mbs B queue of packets waiting for output link 45 Mbs D E

5. 1 Mbit link each user: 100Kbps when “active” active 10% of time circuit-switching: 10 users packet switching: with 35 users, probability > 10 active less than .0004 Packet switching allows more users to use network! Packet switching versus circuit switching N users 1 Mbps link What is statistical multiplexing gain?

6. Great for bursty data resource sharing no call setup Excessive congestion: packet delay and loss protocols needed for reliable data transfer, congestion control Q: How to provide circuit-like behavior? bandwidth guarantees needed for audio/video apps still an unsolved problem Is packet switching a “slam dunk winner?” Packet switching versus circuit switching

7. Goal: move packets among routers from source to destination datagram network: destination address determines next hop routes may change during session analogy: driving, asking directions virtual circuit network: each packet carries tag (virtual circuit ID), tag determines next hop fixed path determined at call setup time, remains fixed thru call routers maintain per-call state Packet-switched networks: routing

8. packets experience delay on end-to-end path four sources of delay at each hop nodal processing: check bit errors determine output link queueing time waiting at output link for transmission depends on congestion level of router transmission A propagation B nodal processing queueing Delay in packet-switched networks Which delay corresponds to bandwidth?

9. Transmission delay: R=link bandwidth (bps) L=packet length (bits) time to send bits into link = L/R Propagation delay: d = length of physical link s = propagation speed in medium (~2x108 m/sec) propagation delay = d/s transmission A propagation B nodal processing queueing Delay in packet-switched networks Note: s and R are very different quantities! High-speed network? High-bandwidth network?

10. R=link bandwidth (bps) L=packet length (bits) a=average packet arrival rate Queueing delay (revisited) traffic intensity = La/R • La/R ~ 0: average queueing delay small • La/R -> 1: delays become large • La/R > 1: more “work” arriving than can be serviced, average delay infinite!

11. roughly hierarchical national/international backbone providers (NBPs) [tier 1] e.g. BBN/GTE, Sprint, AT&T, IBM, UUNet interconnect (peer) with each other privately, or at public Network Access Point (NAPs) regional ISPs [tier 2] connect into NBPs local ISP [tier 3], company connect into regional ISPs a point-of-presence (POP) is an access point from one place to the rest of the Internet local ISP local ISP NAP NAP Internet structure: network of networks regional ISP NBP B NBP A regional ISP

12. National Backbone Provider e.g. Sprint US backbone network

13. Layered approach • What is layering? • A technique to organize a network system into a succession of logically distinct entities, such that the service provided by one entity is solely based on the service provided by the previous (lower level) entity

14. HTTP Packet radio Why layering? • No layering: each new application has to be re-implemented for every network technology! FTP NFS Telnet Application Coaxial cable Fiber optic Transmission Media

15. HTTP Packet radio Why Layering? • Solution: introduce an intermediate layer that provides a unique abstraction for various network technologies FTP NFS Telnet Application Intermediate layer Coaxial cable Fiber optic Transmission Media

16. Layering • Advantages • Modularity – protocols easier to manage and maintain • Abstract functionality: lower layers can be changed without affecting the upper layers • Reuse – upper layers can reuse the functionality provided by lower layers • Disadvantages • Information hiding – inefficient implementations

17. Key Design Decision • How do you divide functionality across the layers?

18. Layering: Hop-by-Hop vs. End-to-End • Think twice before implementing a functionality that you believe that is useful to an application at a lower layer • If the application can implement a functionality correctly, implement it a lower layer only as a performance enhancement

19. OK Example: Reliable File Transfer Host A Host B • Solution 1: make each step reliable, and then concatenate them • Solution 2: end-to-end check and retry Appl. Appl. OS OS

20. Discussion • Solution 1 not complete • What happens if the sender or/and receiver misbehave? • The receiver has to do the check anyway! • Thus, full functionality can be entirely implemented at application layer; no need for reliability from lower layers • Is there any need to implement reliability at lower layers?

21. Discussion • Yes, but only to improve performance • Example: • Assume a high error rate on communication network • Then, a reliable communication service at data link layer might help

22. Trade-offs • Application has more information about the data and the semantic of the service it requires (e.g., can check only at the end of each data unit) • A lower layer has more information about constraints in data transmission (e.g., packet size, error rate) • Note: these trade-offs are a direct result of layering!

23. Rule of Thumb • Implementing a functionality at a lower level should have minimum performance impact on the application that do not use the functionality

24. Internet & End-to-End Argument • Provides one simple service: best effort datagram (packet) delivery • Only one higher level service implemented at transport layer: reliable data delivery (TCP) • Performance enhancement; used by a large variety of applications (Telnet, FTP, HTTP) • Does not impact other applications (can use UDP) • Everything else implemented at application level

25. Key Advantages • The service can be implemented by a large variety of network technologies • Does not require routers to maintain any fined grained state about traffic. Thus, network architecture is • Robust • Scalable

26. What About Other Services? • Multicast? • Quality of Service (QoS)?

27. Summary: Layering • Key technique to implement communication protocols; provides • Modularity • Abstraction • Reuse • Key design decision: what functionality to put in each layer?

28. Summary: End-to-End Argument • If the application can do it, don’t do it at a lower layer -- anyway the application knows the best what it needs • Add functionality in lower layers iff it is (1) used and improves performances of a large number of applications, and (2) does not hurt other applications • Success story: Internet

29. Summary • Challenge of building a good (network) system: find the right balance between: Reuse, implementation effort (apply layering concepts) End-to-end argument Performance • No universal answer: the answer depends on the goals and assumptions!

30. How Internet started?

31. The Problem • Before Internet • different packet-switching networks (e.g., ARPANET, ARPA packet radio) • only nodes on the same physical/link layer network could communicate • want to share room-size computers, storage to reduce expense

32. The Challenge • Interconnect existing networks • … but, packet switching networks differ widely • different services • e.g., degree of reliability • different interfaces • e.g., length of the packet that can be transmitted, address format • different protocols • e.g., routing protocols

33. Possible solutions • Reengineer and develop one global packet switching network standard • not economically feasible • not deployable • Have every host implement the protocols of any network it wants to communicate with • Complexity/node = O(n) • O(n2) global complexity

34. Solution • Add an extra layer: inter-networking layer • hosts: • understand one network protocol • understand one physical/link protocol • gateways: • understand one network protocol • understand the physical/link protocols of the networks they gateway • Complexity to add a node/network: O(1) with respect to number of existing nodes

35. Solution Gateways

36. Common Intermediate Representation • Examples: • telnet, IP, strict HTML, I-mode cHTML • Who ignored this: • US cell phone providers (pairwise roaming agreements) • IE HTML, Netscape HTML, etc. • WAP (WML same purpose as HTML, but not compatible) • network value = O(n2), (Metcalfe's Law) • pairwise translation: cost = O(n2), utility = O(1) • CIR: cost = O(n), utility = O(n)

37. Challenge 1: Different Address Formats • Options: • Map one address format to another. Why not? • Provide one common format • map lower level addresses to common format • Format: • Initially: 8b network 16b host 24b total • Before Classless InterDomain Routing (CIDR): • 7b/24b, 14b/16b, or 21b/8b 32b total • After CIDR: Arbitrary division 32b total • NAT: 32b + 16b simultaneously active • IPv6: 128b total

38. Address Formats • 256 networks? What were they thinking? • Why CIDR? • What happens if they run out before IPv6? • Why IPv6? • Why 128b for IPv6? 248=281 trillion. • Why not variable length addresses?

39. Challenge 2: Different Packet Sizes • Need to define maximum packet size • Options: • Take the minimum of the maximum packets sizes over all networks • Implement fragmentation/reassembly • Flexibility to adjust packet sizes as new technologies arrive • IP: fragment at routers, reassemble at host • Why not reassemble at routers? • Still stuck with 1500B as de facto maximum

40. Other Challenges • Errors  require end-to-end reliability • Thought to be rarely invoked, but necessary • Different (routing) protocols  coordinate these protocols • Accounting • Did not envision script kiddies • Quality of Service • Not addressed

41. Transmission Control Program • Original TCP/IP (Cerf & Kahn) • no separation between transport (TCP) and network (IP) layers • one common header (vestige?) • flow control, but not congestion control (why not?) • fragmentation handled by TCP • Today’s TCP/IP • separate transport (TCP) and network (IP) layer (why?) • split the common header in: TCP and UDP headers • fragmentation reassembly done by IP • congestion control

42. Devil’s Advocate • Who cares about resource sharing? • 1974: cycles, storage, bandwidth expensive, people cheap • 2002: resources cheap, people expensive • 1974: Share computer resources • 2002: Communicate with people, access documents, buy, sell • Does it still make sense to make processes the endpoint?

43. Back to the big picture

44. Goals (Clark’88) • Connect existing networks • initially ARPANET and ARPA packet radio network • Survivability • ensure communication service even in the presence of network and router failures • Support multiple types of services • Must accommodate a variety of networks • Allow distributed management • Allow host attachment with a low level of effort • Be cost effective • Allow resource accountability

45. 1. Survivability • continue to operate even in the presence of network failures (e.g., link and router failures) • failures (excepting network partition) should be transparent to endpoints • maintain state only at end-points (fate-sharing) • no need to replicate and restore router state • disadvantages? • Internet: stateless network architecture • no per-flow state, still have state in address allocation, DNS

46. 2. Types of Services • Add UDP to TCP to better support other types of applications • e.g., “real-time” applications • Probably main reason for separating TCP and IP • Provide datagram abstraction: lower common denominator on which other services can be built • service differentiation considered (ToS header bits) • was not widely deployed (why?)

47. Application Assumptions • Who made them: • Telephone network: voice (web, video?) • Cable: broadcast (2-way?) • X.25: remote terminal access (file transfer?) • BBS: centralized meeting place (web, p2p?) • NAT: client/server model (p2p, IM, IP Telephony?) • Who didn't: Internet • Caveat: best-effort, unicast, fixed location (real-time, multicast, mobility?) • Allows development of unforeseen applications: • Web, p2p, distributed gaming

48. 3. Variety of Networks • Very successful • because the minimalist service; it requires from underlying network only to deliver a packet with a “reasonable” probability of success • …does not require: • reliability, in-order delivery, single delivery, QoS guarantees • The mantra: IP over everything • Then: ARPANET, X.25, DARPA satellite network.. • Now: ATM, SONET, WDM, PPP, USB, 802.11b, GSM, GPRS, DSL, cable modems, power lines

49. Internet Architecture • Packet-switched datagram network • IP is the glue • Hourglass architecture • all hosts and routers run IP • Common Intermediate Representation TCP UDP IP Satellite Ethernet ATM

50. Other Goals • Allow distributed management • each network can be managed by a different organization • different organizations need to interact only at the boundaries • doesn’t work so well for routing, accounting • Cost effective • sources of inefficiency • header overhead • retransmissions • routing • …but routers relatively simple to implement (especially software side)