Internet Architecture and Design Philosophy
Download as PPTX, PDF3 likes1,068 views
The document discusses the architecture and design philosophy of the internet, highlighting key principles such as the end-to-end argument and the hourglass model. It outlines the fundamental goals and trade-offs in the design of TCP/IP protocols, emphasizing the need for survivability, service variety, and distributed management. The summary also indicates that while some goals have been successfully achieved, others have posed challenges, particularly regarding the efficiency of implementations.
![End-to-End Argument [1]
Examines which layer should implement a service
Argue many services should be implemented at
higher layers
e.g., on end hosts
Contributions
Fits with the model of minimal network (IP) layer
Provides guidance on what (not) to add to data link
layers
End-to-end principle is fundamental to Internet success
9](https://image.slidesharecdn.com/01-internetarchitecturedesignphilosophy-180818031552/85/Internet-Architecture-and-Design-Philosophy-9-320.jpg)
![Why TCP/IP? [2]
Objective
Why TCP/IP was designed this way?
DARAP Internet Architecture
1 fundamental goal
Several 2nd level goals
Ordering of 2nd level goals
15](https://image.slidesharecdn.com/01-internetarchitecturedesignphilosophy-180818031552/85/Internet-Architecture-and-Design-Philosophy-15-320.jpg)
Internet Architecture and Design Philosophy
- 1. Internet Architecture & Design Philosophy CS4482 High Performance Networking Dilum Bandara Dilum.Bandara@uom.lk Some slides extracted from Dr. Dan Massey’s CS557 class at Colorado State University
- 2. Outline 1. J.H. Saltzer, D.P. Reed, and D.D. Clark, “End to End Arguments in System Design,” ACM Transactions on Computer Systems, vol. 2, no. 4, Nov. 1984, pp. 277- 288 2. D.D. Clark, “Design Philosophy of the DARPA Internet Protocols,” ACM, 1988 2
- 3. Architecture Dictionary definitions A style & method of design & construction Orderly arrangement of parts Manner of construction of something & disposition of its parts Design, the way components fits together Definitions vary & no one agrees Goal Why the Internet was designed this way? 3
- 6. Hourglass Architecture Why internet layer? Make a big network Global addressing Virtualized network to isolate protocols from network details Why only IP? Maximum interoperability Minimize no of service interfaces Why IP is so narrow? Assumes least common network functionality many networks 6 Steve Deering’s hourglass showing “waist” of the Internet Source: http://isoc.org/wp/ietfjournal/?p=454
- 7. Hourglass Architecture Insufficient 7 Putting on weight Need for more functionality Midlife Crisis Address space not sufficient
- 8. Architecture often seen today 8 Source: http://isoc.org/wp/ietfjournal/?p=454
- 9. End-to-End Argument [1] Examines which layer should implement a service Argue many services should be implemented at higher layers e.g., on end hosts Contributions Fits with the model of minimal network (IP) layer Provides guidance on what (not) to add to data link layers End-to-end principle is fundamental to Internet success 9
- 10. Which Layer? Services Reliable delivery Duplicate message suppression FIFO ordering Delivery guarantees Encryption Transaction Management Recovery from crashes Options Lower layers help application by providing those services Lower layers are of little help as application has the final say 10
- 11. File Transfer – Example Errors can occur at many levels Transfer from sender disk to memory Transfer from sender OS to sender line card Transfer across network Transfer from receiver line card to receiver OS Transfer from receiver memory to disk What would be the effect of a perfectly reliable network? Does not recover from other errors Provides a false sense of security Impact other applications that don’t need those services 11
- 12. Tradeoffs As far as application has to perform its own checking, extra effort at network level is of little help End systems have information on semantics & requirements Application state Network has information on data transmission parameters (packet size, error rate) Assuming packets follow the predicted path 12
- 13. Other Examples Delivery guarantees Did the end act upon the received message? Encryption Clear data before entering the secure network Duplicate message suppression Applications may retry, e.g., remote login FIFO ordering In distributed systems with multiple destinations Recovery from crashes What if the network failed & all state is lost? 13
- 14. Rules of Thumb Consider marginal gain in lower layer If you can achieve large impact with limited effort, go for it Consider impact on other services Implement at lower layer, only if minimal impact on applications that don’t use that service General Result Implement services at the end, not inside the network 14
- 15. Why TCP/IP? [2] Objective Why TCP/IP was designed this way? DARAP Internet Architecture 1 fundamental goal Several 2nd level goals Ordering of 2nd level goals 15
- 16. Fundamental Goal Allow connection of many existing networks Effective technique for multiplexed utilization of existing interconnected networks Some important assumptions Connect ARPANET with ARPA packet radio Networks represent administrative boundaries Rely on packet switching & store and forward Net result Packet switched network consisting of distinct networks with store & forward gateways between them 16
- 17. 2nd Level Goals 1. Function despite loss of networks/gateways 2. Support multiple types of services 3. Accommodate a variety of networks 4. Distributed management of resources 5. Cost effective 6. Low level of effort to add a host 7. Provide accounting of resources used What else could a network designer ask for? 17
- 18. Fundamental Trade-Offs All goals can’t be satisfied equally Which goals win & which lose in the trade-off? Order of goals is essential Very strong focus on first 3 Survive network & gateway failures Provide different types of services Accommodate a variety of networks See a connection to hourglass model? A different order would produce a different design e.g., accounting barely works at all in the Internet 18
- 19. Survivability Links & Gateways will fail & stop working Design didn’t anticipate misbehaviour Source has no physical path to destination 2 entities can continue to communicate Despite faults at any intermediate point Mask any transient failures, e.g., route changes Break only if total network partition See a connection to end-to-end principle? 19
- 20. Achieving Survivability Implications for storing network state Failure of intermediate nodes loss of state Must replicate state stored at intermediate nodes Replication is difficult Clever Solution State only stored at edges Stateless packet switches (middle of network) State at the edge e.g., TCP state: seqnum, acknum, window, etc. Fate-sharing Acceptable to lose the state if the host itself has failed 20
- 21. Types of Services Virtual circuit service (TCP) Bi-directional reliable delivery Differing goals even within this service High bandwidth, delay not so important, e.g., file transfer Low latency, bandwidth less important, e.g., Telnet Other services Low complexity, no reliability, e.g., debugging Predictable rate with minimal jitter, e.g., voice Reliability is counterproductive 21
- 22. Types of Services (Cont.) Split TCP/IP as 2 separate layers TCP (transport) & IP (network) Datagram as basic building block No assumption desired service is present in underlying network Build services such as TCP or UDP at the end hosts 22
- 23. Variety of Networks Assumptions regarding underlying network Transport a packet with reasonable packet size Reasonable (but not perfect) reliability Reliability proved a problem for sending voice Assumptions that weren’t used Reliable or sequenced delivery Network broadcast or multicast Priorities or services Failures, speeds, or delays Minimal set of functionalities Build other services at host, e.g., TCP for reliability 23
- 24. Other Goals Distributed management Success in allowing multiple domains (2 tier routing) Failure in routing policies Cost Effective Longer headers reduce efficiency Retransmission at the ends reduces efficiency Adding Hosts Host software is complex Relies on correct implementations at the host Misbehaviour is a real problem today Accounting Challenges of datagram model May prefer flows for accounting 24
- 25. Implementations Proven to meet goal of network variety Some high speed, some not Some highly redundant, some single point of failure This failure is due to the implementation, not the design Leaves much of the work for implementation What bandwidth? What redundancy? Performance Goals Little good guidance Limited effective simulation Specifying Performance Must specify it, or you won’t get it Leave it to network administrators to specify performance goals 25
- 26. Summary Identified & Prioritized Goals Top 3 goals very successful Bottom goals less successful Building block – datagram Very effective for top goals Suggests “flows” may be better (for different priorities of goals) Suggests Period Messages – Soft-state 26
Editor's Notes
- #16: DARPA – Defence Advanced Research Project Agency