Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Internet Architecture and Design Philosophy

255 views

Published on

Design Philosophy and fundamental goals behind Internet. End-to-End Argument. TCP/IP Hourglass Architecture

Published in: Engineering
  • Be the first to comment

  • Be the first to like this

Internet Architecture and Design Philosophy

  1. 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. 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. 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
  4. 4. 4 OSI Stack Source: http://walkwidnetwork.blogspot.com/2013/04/physical-layer-osi-model.html
  5. 5. Layered Design 5 Source: http://blog.anuesystems.com/category/span-and-taps/
  6. 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. 7. Hourglass Architecture Insufficient 7 Putting on weight Need for more functionality Midlife Crisis Address space not sufficient
  8. 8. Architecture often seen today 8 Source: http://isoc.org/wp/ietfjournal/?p=454
  9. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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

×