1. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 Review of Networking and Design Concepts (II) Two ways of constructing a software design: 1)make it so simple that there are obviously no deficiencies, and 2)make it so complicated that there are no obvious deficiencies --- CAR Hoare Based in part upon slides of Prof. Raj Jain (OSU), J. Kurose (U Mass), I. Stoica, A.Joseph (UCB)

2. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 2 q Protocols, layering, encapsulation q Function-placement: End-to-end principle q Implementation: App-layer framing, ILF q Interface design: functionality, technology, performance q Rules of thumb in system design q Chapter 1,2,11 in Doug Comer book q Reading: Saltzer, Reed, Clark: "End-to-End arguments in System Design""End-to-End arguments in System Design" q Reading: Clark: "The Design Philosophy of the DARPA Internet Protocols":"The Design Philosophy of the DARPA Internet Protocols": q Reading: RFC 2775: Internet Transparency: In HTMLIn HTML Overview

3. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 3 Protocols Human protocol vs Computer network protocol: A series of functions performed at different locations. Hi Got the time? 2:00 TCP connection req. TCP connection reply. Get http://www.rpi.edu/index.htm time

4. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 4 Why Layering? q No layering: each new application has to be re-implemented for every network technology! Telnet FTPNFS Packet radio Coaxial cable Fiber optic Application Transmission Media HTTP (FTP – File Transfer Protocol, NFS – Network File Transfer, HTTP – World Wide Web protocol)

5. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 5 Why Layering? q Solution: introduce an intermediate layer that provides a unique abstraction for various network technologies Telnet FTPNFS Packet radio Coaxial cable Fiber optic Application Transmission Media HTTP Intermediate layer

6. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 6 What is Layering? q 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

7. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 7 Layering q Advantages q Modularity – protocols easier to manage and maintain q Abstract functionality –lower layers can be changed without affecting the upper layers q Reuse – upper layers can reuse the functionality provided by lower layers q Disadvantages q Information hiding – inefficient implementations

8. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 8 Protocols q Building blocks of a network architecture q Each protocol object has two different interfaces q service interface: defines operations on this protocol q peer-to-peer interface: defines messages exchanged with peer service interface peer interface L i+1 LiLi LiLi

9. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 9 ISO OSI Reference Model q Seven layers q Lower three layers are peer-to-peer q Next four layers are end-to-end Application Presentation Session Transport Network Datalink Physical Application Presentation Session Transport Network Datalink Physical Network Datalink Physical Physical medium

10. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 10 Encapsulation q A layer can use only the service provided by the layer immediate below it q Each layer may change and add a header to data packet data

11. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 11 OSI vs. TCP/IP q OSI: conceptually define services, interfaces, protocols q Internet: provide a successful implementation Application Presentation Session Transport Network Datalink Physical Internet Host-to- network Transport Application IP LAN Packet radio TCPUDP TelnetFTPDNS OSITCP

12. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 12 Example: Transport Protocol (Logical Communication) q take data from app q add addressing, reliability check info to form “datagram” q send datagram to peer q wait for peer to ack receipt q analogy: post office application transport network link physical application transport network link physical application transport network link physical application transport network link physical network link physical data transport ack (Source: Kurose & Ross)

13. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 13 Example: Transport Protocol (Physical Communication) (Source: Kurose & Ross) application transport network link physical application transport network link physical application transport network link physical application transport network link physical network link physical data

14. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 14 Key questions q How to decompose the complex system functionality into protocol layers? q What functions to be placed at which levels? q Can a function be placed at multiple levels ?

15. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 15 Common View of the Telco Network Brick

16. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 16 Common View of the IP Network

17. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 17 End-to-End Argument q “…functions placed at the lower levels may be redundant or of little value when compared to the cost of providing them at the lower level…” q “…sometimes an incomplete version of the function provided by the communication system (lower levels) may be useful as a performance enhancement…” q This leads to a philosophy diametrically opposite to the telephone world which sports dumb end- systems (the telephone) and intelligent networks.

18. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 18 Example: Reliable File Transfer q Solution 1: make each step reliable, and then concatenate them q Solution 2: end-to-end check and retry OS Appl. OS Appl. Host AHost B OK

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

20. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 20 Discussion q Yes, but only to improve performance q Example: q assume a high error rate on communication network q then, a reliable communication service at datalink layer might help

21. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 21 Trade-offs q 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) q A lower layer has more information about constraints in data transmission (e.g., packet size, error rate) q Note: these trade-offs are a direct result of layering!

22. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 22 Internet & End-to-End Argument q At network layer provides one simple service: best effort datagram (packet) delivery q Only one higher level service implemented at transport layer: reliable data delivery (TCP) q performance enhancement; used by a large variety of applications (Telnet, FTP, HTTP) q does not impact other applications (can use UDP) q Everything else implemented at application level

23. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 23 Key Advantages q The IP service can be implemented on top of a large variety of network technologies q Does not require routers to maintain any fined grained state about traffic. Thus, network architecture is q Robust q Scalable

24. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 24 What is a “level” of a system? q Protocol “layer” = “level” q Within a single layer, closer to the core => “lower” level q Eg: Edge-boxes of a domain implementing functions like firewalls, address translation, QoS functions are at a “lower” level compared to other boxes in the domain q Core router is “lower” level compared to an “edge router” q In hierarchical routing, use of smaller prefixes correspond to lower levels of the system.

25. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 25 E2E Argument: Interpretations q One interpretation: (limited in my opinion…) q A function can only be completely and correctly implemented with the knowledge and help of the applications standing at the communication endpoints q Another: (more precise…) q a system (or subsystem level) should consider only functions that can be completely and correctly implemented within it. q Alternative interpretation: (also correct …) q Think twice before implementing a functionality that you believe that is useful to an application at a lower layer q If the application can implement a functionality correctly, implement it a lower layer only as a performance enhancement

26. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 26 End-to-End Argument: Critical Issues q The end-to-end principle emphasizes: q function placement q correctness q completeness and q overall system costs. q It allows a cost-performance tradeoff q If implementation of function in higher levels is not possible due to technological/economic reasons (eg: telephone network in early 1900s), then it may be placed at lower levels

27. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 27 Summary: End-to-End Arguments q If the application can do it, don’t do it at a lower layer -- anyway the application knows the best what it needs q 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 q Success story: Internet

28. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 28 Architecture vs Implementation: ALF Principle q Architecture: decomposition into functional modules, semantics of modules and syntax used q There should be no a priori requirement that the engineering design of a given system correspond to the architectural decomposition q Eg: layering may not be most effective modularity for implementation q Summary: q Flexible decomposition q Defer engineering decisions to implementor. q Avoid gratuitous implementation constraints q Maximize engineering options for customization/optimization

29. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 29 Application Layer Framing (ALF) q Several processing bottlenecks may lie at the “presentation” layer which does not really exist in the TCP/IP stack q These functions are absorbed partially in the transport layer and partly in the application layer. q Principle: the application-layer should have control of the syntax and semantics of the presentation conversions q Transport should provide only common functions q Generalization of ALF: look for elegant ways to allow application visibility/participation in lower-level activities q Eg: QoS – carry application intelligence to the point of QoS enforcement

30. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 30 ILP: Integrated Layer Processing q Motivation: ever-widening memory / CPU bottleneck q “Integrated processing loop” q Loop over bytes in packet q Touch each byte at most once q Avoid multiple copies within memory q Massive integrated loop w/ all steps in-line q Trivial example: bcopy + checksum q Architecture must minimize gratuitous precedence or ordering constraints …

31. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 31 Eg: Real-Time Protocol q RTP svcs: payload type identification, sequence numbering, timestamping and delivery monitoring q “RTP is intended to be malleable to provide the information required by a particular application and will often be integrated into the application processing rather than being implemented as a separate layer.” q RTP is a protocol framework that is deliberately not complete and can be tailored modifications/additions to the headers. q RTP specifies only common functions for its apps q Avoid taking on additional functions q making the protocol more general or q Adding options requiring expensive parsing

32. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 32 Interface Design q Driven by three factors: q Functionality: what features the customer wants, and is placed at a level due to e2e principle etc q Technology: what’s possible. Building blocks and techniques q Performance: How fast etc… User, Designer, Operator views of performance.. q Interface design crucial because interface outlives the technology used to implement the interface.

33. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 33 Performance q Performance questions: q Absolute: How fast …  Relative: Is A faster than B and how much faster? q Define system as a black box. q Parameters: input; Metrics: output q Parameters: only those the system is sensitive to q Metrics: must reflect the system design tradeoff System Parameters Metrics

34. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 34 Effect on Design: Amdahl’s law q Performance after improvement = Performance affected by improvement / speedup + Unaffected performance q Lesson: Speedup the common case I.e. the parts that matter most !! q Amdahl’s law guides the definition of tradeoffs, parameters, test cases and metrics !

35. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 35 Perspectives on Performance/Design q Network users: services and performance that their applications need, q Network designers: cost-effective design q Network providers: system that is easy to administer and manage q Need to balance these three needs

36. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 36 System Design Rules of Thumb q Design a system to tradeoff cheaper resources against expensive ones (for a gain) q When resources are cheap and abundant, waste them. Design focuses on cutting out any expensive resource that comes in the way! (eg: parallelism) q Filtering => Efficiency => Scalability q Apply principles like E2E and ALF to decide on right placement of functionalities in different system levels q Interfaces must outlive several generations of change in the components being interfaced. q Three factors drive interface design: q functionality demanded, q available technology, q performance tradeoff.

37. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 37 q Functionality requirements can be understood by taking different views of the system (eg: designer, implementor, operator). q Reduced functionality can result in cheaper, scalable, quickly engineered system q Placement of functionality is critical in system design q No paradigm is going to work or functionality can be met if the available technology to implement it does not exist. q Performance is either relative or absolute and is usually modeled at the high level as a function from system parameters (input) to system metrics (output). q Metrics must be design to reflect design tradeoffs. q Only sensitive parameters matter. q Optimize the common case (Amdahl’s law) q Solve 90% of the problem that matters, throw away the remaining 10% of the problem requirements!