Network Protocols: Design and Analysis

1. Network Protocols: Design and Analysis Polly Huang EE NTU http://cc.ee.ntu.edu.tw/~phuang phuang@cc.ee.ntu.edu.tw

2. The Internet Design Philosophy [Clark88a] [Deering98a] [Saltzer81a] [Saltzer82a]

3. The Internet Architecture[Clark88a]

4. Key Ideas • Defines (after-the-fact) the internet architecture • Architecture on following slides, but: • Datagrams • Multiple link layers • Multiple applications and application classes

5. The Dream Internet • How it should be like • The starting point -- IP • The expansion ground -- around IP • The attitude -- desired property

6. The IP • Connectionless datagrams (IP) at lowest level • Packet switching as opposed to circuit switching • Routers and routing protocols • The packet switching infrastructure

7. Around IP • Multiple protocols on top of that • TCP, UDP, etc. • Multiple applications on top of that • Web, e-mail, etc. • Multiple link layers underneath IP: • LANs: Ethernet • last-mile: PPP, ISDN, cable modems, DSL • “backbone”: Sonet, ATM, others

8. Desired Properties • Availability • Reliability • Survivability • Scalability (hopefully)

9. The Goals Making them concrete

10. The Internet Architecture • Inter-connecting heterogeneous networks • Multiplexing via packet switching

11. Sub-goals • Robust to network/gateway failure • Multiple kinds of traffic • Multiple kinds of networks • Distributed management • Inexpensive • Low effort to add host • Resource accounting

12. Not Original Goals • Quality of Service

13. Main Goals • Heterogeneous networks • Why? • Allow independent evolution of link-layers • multiple LANs, last-mile, and POP-to-POP technologies • Multiplexing • Packet switching fundamentally different from circuit switching

14. Back in the Old Days... the “router” (Aunt Mable) the wire 1920s telephony: circuits---a physical wire from one end to the other

15. Then Came TDM... Time Division Multiplexing mux demux … but keeps the idea of a fixed pipe (circuit) the right size for a telephone conversation

16. And FDM and CDM... Frequency Division Multiplexing a a a a a a a a a a a a a a a a a a a a a a Code Division Multiplexing

17. Logical Network View • fixed size pipe from her to him • perfect for voice • reliable conversations (QoS) • provisioning, good engineering • dumb end points, smart network • evolved for 100 years (analog to digital) Quality of Service

18. Packet Switching (Internet) • differences: • packets as low-level component • multiple kinds of traffic • smart edges, dumb network • but: • QoS is much harder • end-points are more expensive • fast routers could be harder (but also probably less complex)

19. Statistical Multiplexing Gain Assumptions: 1 Mb/s link user: 0.1Mb/s when transmitting, but 10% duty cycle • Circuit switching: can support 10 users, 100% reliable • Packet switching: with 35 users, probability that >=10 are transmitting at the same time = 0.0004

20. Robust to Failures • Application should not see transient failures • Failures • Node/link failure (find an alternate path) • Packet lost due to congestion (queue overflow), • Packet lost due to transmission errors (node failures)

21. Thus, Rule #1 • All states at endpoints • States set by datagrams • Retransmit if packets lost • The philosophy • Fate-sharing • If end crashes, it doesn’t care

22. And, Rule #2 • Some states are only appropriate to be kept in the network • States set by control messages • Periodic refresh in case of un-sync states • The philosophy • Soft-state • Periodically repeat the state • To allow recovery from lost info, without specific action per failure

23. Originally just NCP, but split to {TCP,UDP}/IP Why? Varying needs in speed, latency, reliability Not just bi-directional reliable data "virtual circuit" IP: best effort datagram Bad if link layer wants to do too much PILC working group in IETF today TCP Interactive, low-latency Bulk delivery UDP Lightweight Out-of-order to user Low-latency & jitter, RT possible for voice Reliability is biggest source of jitter Multiple Types of Service

24. RDP: Reliable Delivery Protocol Message-based Allows out-of-order delivery RFC-908 SCTP: Stream Control Transmission Protocol Intended for telephony signaling over IP Multiplexes multiple “streams” per connection In-sequence per stream, out-of-sequence between streams Reliable RFC-3286 DCCP: Datagram Congestion Control Protocol Add congestion control to UDP In progress XCP: Explicit Control Protocol High-speed streaming with explicit router rate feedback Presented at SIGCOMM Non-TCP/UDP protocols

25. Classes of applications Web File transfer (Napster, etc.) Remote login Streaming audio Interactive audio Streaming/interactive video Computer appliances Others? Requirements: Loss resilience Delay/jitter sensitivity Bursty/smooth Point-to-point vs. n-way Numbers of sources and sinks Multiple Applications

26. IP over X Compare to integrated stacks: ISO ATM Fibre channel, Apple Desktop Bus, USB But a counter example: SCSI and now SCSI over IP Requirements of X: Reasonable size packets But fragmentation and reassembly Reasonable reliability But workarounds Addressing Non-requirements of X: Reliable, in-order, broadcast, QoS, etc. Multiple kinds of networks

27. Other goals • Distributed management • Some work, and today policy routing exists • But limitations (ex. address space portability) • Cost effective • Today quite cheap • But for small devices? for keyboard?

28. Other other goals • Effort to deploy end host • For him in ’88: cost of implementing stack • Today: cost of administering machine • Much lower today (DHCP, etc.) • But still lots of manual configuration “futzing” • Accountability • Basically nothing then • Today: PPPoE created just for authentication

29. Architecture and Implementation • Realization: an instance of the Internet class • Him: 1200b/s modem vs. 1Mb/s LAN • Today: the Internet can’t do X because it is Y • ex. can’t do System Area Networks over IP because it’s too slow, so we need Fibre Channel • alternative: build a fast Internet realization • Corollary: not every realization is appropriate for every application • Also: custom stack will get last 5% of performance, but is it worth it?

30. TCP Features • Features: • Connection establishment, connectionless communication, • Congestion avoidance, flow control, • Duplicate packet detection, loss recovery, • Ordered data delivery to the application, out-of-order data delivery to the application, • Differentiated services, quality-of-service, urgent data indication • Message or record boundaries,

31. TCP Alternative Choices • Byte stream vs. message stream • Flow control • Congestion control came later • PSH flag • A weak record boundary • But the reason the Plan-9 people didn’t use TCP

32. Other Components of IP Success • A good, free implementation • BSD Unix in the mid-80’s • Compare to OSI where implementations were late • A good API • BSD socket API • Not perfect, but good • Compare to OS’s where Unix and Windows have very different APIs to open/rename/etc. files

33. Questions?

34. Watching the Waist of IP[Deering98a]

35. Key Idea • The importance of a single, narrow layer for interoperability • In the Internet, it’s IP • Many link layers and hardware below • many protocols and applications above • One network layer to rule them all, one network layer to bind them…

36. IP

37. Why a single, narrow protocol? • Why single: • Maximize interoperability • Minimize amount of work needed to support new protocols • Why narrow: • Minimize requirements from lower layers • End-to-end argument: don’t want to weigh down IP with a bunch of things that are unnecessary by many of its users

38. What are the key IP properties? • Small and simple • Connectionless datagram • Global addressing • Maximize connectivity • Much harder to provide global addressability at higher layer • Enable applications (ex. peer-to-peer file sharing) • But addressability make security harder => NAT boxes, firewalls

39. Why add to or change IP? • More features are cooler • QoS, multicast, … • More features make more money • Replacing it makes lots of money • And could do new things if everyone buys in • Ex. ATM • Have short-term (?) problems that have to be solved (via work-arounds) • Address space size: NAT

40. Other questions/observations? • Active network: idea that end-users (or admins) should be able reprogram the network • Size of IP headers: 40B is this a problem • Interactions w/ATM or other link-layers w/short MTUs • Could be problem (high overhead) for telnet • QoS and multicast • Why not depoyed? increase assumptions lower layers, we need to change all routers, not everyone needs services, difficult to transition research into company, maybe can do these things above IP…

41. Questions?

42. The End-to-End Argument: [Saltzer81a]

43. Key Idea • The end-to-end argument • Don’t duplicate functionality in multiple levels if you have to do it at the top anyway

44. Key ideas • Where should services (encryption, reliability, ordering, duplicate suppression) be placed: at the end points or in the network? • Since these can be done at higher layers, and expensive to to do these at the lower layers, maybe just do them at the ends • Especially if the ends MUST do it • But maybe performance motivates putting it also at lower layers

45. Example: Reliability • Consider copying a file • Want an end-to-end checksum • Steps: • A reads from disk to mem; sends to network • Network moves data from A to B • B gets data from network; writes to disk • Possible faults: • Disk IO errors, buffer overruns in NIC, memory errors, network corruption or congestion, computer crashes

46. Other examples in paper • Encrypted data transfer • Duplicate message suppression • Guaranteed FIFO message delivery • Transactions in a DB

47. Other examples? • Instant messaging uses UDP, the application provides reliability • Congestion control • Microkernels: minimal operating system functionality • RPC systems: remote procedure call (and reliability)

48. Caveat: performance • Consider file copy again • Reliability at physical, link, network, transport, application layers • Ex. in wireless, might want hop-by-hop reliability because the loss/corruption rate is much higher than wired networks • Multiple levels may be needed for performance

49. Challenge: Defining the “End” • Ex. security: what is the protocol and end for each app? • Ordering over web at Amazon.com? ends customers web browser and Amazon’s transaction server • Connecting over the Internet to USC with a VPN? network sideyour computer, (end server on) USC network [my PC to USC’s network] • Using a wireless base-station with WEP? my computer to the access point/wireless LAN • Entering my PIN at a bank ATM? human to bank (?)

50. Why is End-to-End Important to Network Design?