Internet Design PapersEnd-to-End Argument in System DesignIntroductionSlide 4Example: Careful File TransferHow to provide reliabilitySlide 7Slide 8The Design Philosophy of the DARPA Internet ProtocolsSlide 10Fundamental GoalSecond level goalsSurvivability in the face of failuresHow to protect state info from lossSlide 15Types of ServiceVarieties of networksOther goalsOther goals – cont’dArchitecture and ImplementationDatagramsTCPConclusionsSome thoughts on the face of end-to-end argument…Internet Design PapersEnd-to-End Argument in System DesignSaltzer, Reed, ClarkACM Transactions on Computer Systems1984IntroductionEnd-to-end argumentfunctions placed at low levels of a system may be redundant or of little value when compared with the cost of providing them at that low levelIn a layered system, move a function upward closer to the application that uses itExamplesReliable data transmissionBit-error recoverySecurity using encryptionDuplicate message suppressionRecovery from system crashesDelivery acknowledgementIntroductionWhen designing a network, need to decide where to implement a list of functions to be supportedIn the networkAt the edge by clientsAs a joint ventureRedundantly at both placesThe function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the endpoints of the network. Therefore, providing that questioned function as a feature of the communication system itself is not possible. (Sometimes an incomplete version of the function provided by the network may be useful as a performance improvement.)Example: Careful File TransferMove a file from disk of computer A to disk of computer BRead from disk at APass to file xfer program at ATransfer from A to BPass pkts to file xfer program at BPass file to OS to write on disk at BProblems that may occur1- Hardware faults may cause problems2- File xfer program may cause problems3- Transient errors at processor/memory4- Packets may be dropped/corrupted/duplicated in transit5- Hosts may crash in the middle of the transactionHow to provide reliabilityReinforce each step along the way using Duplicate copies, timeout and retry, redundancy for error detection, crash recovery, etcGoal is to reduce the prob. of each threat to an acceptable levelHow about the overhead; what if the probability of all threats occurring is low…Alternative: end-to-end check and retryUse a checksum for each file stored in the diskTransfer file to B using simple procedureAt B, at the end of the xfer, compute checksum and send it back to AIf A finds out a mismatch between checksums, it will re-xferGood if failures are fairly rareHow to provide reliabilityIf we use the first approach for the communication system, threat (4) may be eliminated but still need end-to-end checksum of the fileReliable xmission reduces the frequency of retries (performance improvement) but has no effect on correctness of the outcomecorrect file xmission is ensured by the end-to-end checksum and retryFor the network to go out of its way to be extraordinarily reliable does not reduce the burden on the application program to ensure reliabilityHow to provide reliabilityPerformance aspectsWhat if the frequency of network errors is largeExponential increase in retries with the increasing file lengthSome effort at lower levels to improve network reliability can have a significant effect on appl performance but it should not strive for providing perfect reliabilityThe trade-off is based on performance, not correctnessIf network is too unreliable, file xfer appl will suffer moreIf network is made very reliable, these measures have a performance cost (bw cost, delay cost, processing cost, etc)What is the proper trade-off then?Depends on the characteristics of the network and requirements of the applications to run on top of itThe Design Philosophy of the DARPA Internet ProtocolsDavid D. ClarkMITSIGCOMM 88IntroductionInternet architectureWas first developed in 1970sUnder the Internet Research Program of Defense Advanced Research Project Agency (DARPA) of the US Department of DefenseThe design philosophy has evolved during time and still evolvingThis paper catalogs one view of the original objectives of the Internet architecture, and discusses the relation between these goals and the important features of the protocolsFundamental GoalTo develop an effective technique for multiplexed utilization of then existing networksTo provide some larger service architectureAllow users on networks to access services in other networksIntegrate a number of separately administrated entities into a common utilityTechnique selected for multiplexing: packet switchingAn alternative such as circuit switching could have been considered, but the applications being supported, such as remote login were served by packet switching paradigm. Also the networks that were to be integrated together were packet switching networks.The fundamental structure of the Interneta packet switched network in which a number of networks are connected together using gateways which implement a store and forward packet forwarding algorithmSecond level goalsMust continue despite loss of network or gatewaysMust support multiple types of communication servicesMust accommodate a variety of networksMust permit distributed management of its resourcesMust be cost effectiveMust permit host attachment with a low level of effortResources used must be accountableNote that the ordering of the above items is important and entirely different network architecture would result if changed !Survivability in the face of failuresOne important goal is that the Internet should continue to support communication service even though networks and gateways are failingThe assumption wassynchronization between communication ends would never be lost unless there was no physical path over which any sort of communication could be achievedTo achieve this goalthe state information which describes the on-going conversation must be protected from lossNumber of packet transmitted and/or acknowledgedNumber of outstanding flow control permissions, etcHow to protect state info from lossReplicationStore the state info in the switching nodes of the networkDue to its distributed nature,
View Full Document
Unlocking...