View source for End-to-end principle

{{Short description|Design principle for computer networking}}
{{Net neutrality}}

The '''end-to-end''' ('''E2E''') '''principle''' is a design principle in [[computer network]]ing that requires application-specific features (such as [[Reliability (computer networking)|reliability]] and security) to be implemented in the communicating [[end node]]s of the network, instead of in the network itself. Intermediary nodes (such as [[Gateway (telecommunications)|gateways]] and [[Router (computing)|routers]]) that exist to establish the network may still implement these features to improve efficiency but do not guarantee end-to-end functionality.

The essence of what would later be called the end-to-end principle was contained in the work of [[Donald Davies]] on [[packet-switched network]]s in the 1960s. [[Louis Pouzin]] pioneered the use of the end-to-end strategy in the [[CYCLADES]] network in the 1970s.<ref name="Bennett2009">{{cite web |last1=Bennett |first1=Richard |date=September 2009 |title=Designed for Change: End-to-End Arguments, Internet Innovation, and the Net Neutrality Debate |url=https://www.itif.org/files/2009-designed-for-change.pdf |access-date=11 September 2017 |publisher=Information Technology and Innovation Foundation |pages=7, 9, 11 |quote=Two significant packet networks preceded the TCP/IP Internet: ARPANET and CYCLADES. The designers of the Internet borrowed heavily from these systems, especially CYCLADES ... The first end-to-end research network was CYCLADES, designed by Louis Pouzin at IRIA in France with the support of BBN's Dave Walden and Alex McKenzie and deployed beginning in 1972.}}</ref><ref name=":0" /> The principle was first articulated explicitly in 1981 by [[Jerome H. Saltzer|Saltzer]], [[David P. Reed|Reed]], and [[David D. Clark|Clark]].<ref name="SRC1981" />{{efn|The 1981 paper<ref name="SRC1981" /> was published in ACM's TOCS in an updated version in 1984.<ref name="SRC1984" /><ref name="SAL1980" />}} The meaning of the end-to-end principle has been continuously reinterpreted ever since its initial articulation. Noteworthy formulations of the end-to-end principle can be found before the seminal 1981 Saltzer, Reed, and Clark paper.<ref name="SRC1984" />

A basic premise of the principle is that the payoffs from adding certain features required by the end application to the communication subsystem quickly diminish.  The end hosts have to implement these functions for correctness.{{efn|The full quote from the Saltzer, Reed, Clark paper states:<ref name="SRC1984" /> "In a system that includes communications, one usually draws a modular boundary around the communication subsystem and defines a firm interface between it and the rest of the system. When doing so, it becomes apparent that there is a list of functions each of which might be implemented in any of several ways: by the communication subsystem, by its client, as a joint venture, or perhaps redundantly, each doing its own version. In reasoning about this choice, the requirements of the application provide the basis for the following class of arguments: The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the endpoints of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible, and moreover, produces a performance penalty for all clients of the communication system. (Sometimes an incomplete version of the function provided by the communication system may be useful as a performance enhancement.) We call this line of reasoning against low-level function implementation the end-to-end argument." (p. 278).}} Implementing a specific function incurs some resource penalties regardless of whether the function is used or not, and implementing a specific function ''in the network'' adds these penalties to all clients, whether they need the function or not.

==Concept==
[[File:End-to-end Concept-en.svg|thumb|According to the end-to-end principle, the network is only responsible for providing the terminals with best-effort connections. Features such as reliability and security must be provided by mechanisms and protocols located at the terminals.]]
The fundamental notion behind the end-to-end principle is that for two [[Process (computing)|processes]] communicating with each other via some communication means, the ''[[Reliability (computer networking)|reliability]]'' obtained from that means cannot be expected to be perfectly aligned with the reliability requirements of the processes. In particular, meeting or exceeding very high-reliability requirements of communicating processes separated by networks of nontrivial size is more costly than obtaining the required degree of reliability by positive end-to-end acknowledgments and retransmissions (referred to as [[Positive acknowledgment with re-transmission|PAR]] or [[Automatic repeat request|ARQ]]).{{efn|In fact, even in [[local area network]]s there is a non-zero probability of communication failure{{snd}} "attention to reliability at higher levels is required regardless of the control strategy of the network".<ref name="Clark1978" />}} Put differently, it is far easier to obtain reliability beyond a certain margin by mechanisms in the ''end hosts'' of a network rather than in the ''intermediary nodes'',{{efn|Put in economics terms, the [[marginal cost]] of additional reliability in the network exceeds the marginal cost of obtaining the same additional reliability by measures in the end hosts. The economically efficient level of reliability improvement inside the network depends on the specific circumstances; however, it is certainly nowhere near zero:<ref name="SRC1984" /> "Clearly, some effort at the lower levels to improve network reliability can have a significant effect on application performance. (p. 281)."}} especially when the latter are beyond the control of, and not accountable to, the former.{{efn|The possibility of enforceable contractual remedies notwithstanding, it is impossible for any network in which intermediary resources are shared in a non-deterministic fashion to guarantee perfect reliability. At most, it may quote statistical performance averages.}} Positive end-to-end acknowledgments with infinite retries can obtain arbitrarily high reliability from any network with a higher than zero probability of successfully transmitting data from one end to another.{{efn|More precisely:<ref name="Sunshine1975" /> "THM 1: A correctly functioning PAR protocol with infinite retry count never fails to deliver, loses, or duplicates messages. COR 1A: A correctly functioning PAR protocol with finite retry count never loses or duplicates messages, and the probability of failing to deliver a message can be made arbitrarily small by the sender." (p. 3).}}

The end-to-end principle does not extend to functions beyond end-to-end error control and correction, and security. E.g., no straightforward end-to-end arguments can be made for communication parameters such as [[Latency (engineering)|latency]] and [[throughput]]. In a 2001 paper, Blumenthal and Clark note: "[F]rom the beginning, the end-to-end arguments revolved around requirements that could be implemented correctly at the endpoints; if implementation inside the network is the only way to accomplish the requirement, then an end-to-end argument isn't appropriate in the first place."<ref name="BC2001" />{{rp|80}}

The end-to-end principle is closely related, and sometimes seen as a direct precursor, to the principle of [[net neutrality]].<ref>{{cite web|url=https://www.theatlantic.com/technology/archive/2014/04/the-best-writing-on-net-neutrality/361237/|title=Net Neutrality: A Guide to (and History of) a Contested Idea|publisher=The Atlantic|author1=Alexis C. Madrigal |author2=Adrienne LaFrance |name-list-style=amp|date=25 Apr 2014|access-date=5 Jun 2014|quote=This idea of net neutrality...[Lawrence Lessig] used to call the principle e2e, for end to end}}</ref>

==History==
In the 1960s, [[Paul Baran]] and [[Donald Davies]], in their pre-[[ARPANET]] elaborations of networking, made comments about reliability. Baran's 1964 paper states: "Reliability and raw error rates are secondary. The network must be built with the expectation of heavy damage anyway. Powerful error removal methods exist."<ref name="Bar1964" />{{rp|5}} Going further, Davies captured the essence of the end-to-end principle; in his 1967 paper, he stated that users of the network will provide themselves with error control: "It is thought that all users of the network will provide themselves with some kind of error control and that without difficulty this could be made to show up a missing packet. Because of this, loss of packets, if it is sufficiently rare, can be tolerated."<ref name="Dav1967" />{{rp|2.3}}

The ARPANET was the first large-scale general-purpose packet switching network{{snd}} implementing several of the concepts previously articulated by Baran and Davies.<ref name=":16">{{Cite news |title=The real story of how the Internet became so vulnerable |url=http://www.washingtonpost.com/sf/business/2015/05/30/net-of-insecurity-part-1/ |url-status=dead |archive-url=https://web.archive.org/web/20150530231409/http://www.washingtonpost.com/sf/business/2015/05/30/net-of-insecurity-part-1/ |archive-date=2015-05-30 |access-date=2020-02-18 |newspaper=Washington Post |language=en-US |quote=Historians credit seminal insights to Welsh scientist Donald W. Davies and American engineer Paul Baran}}</ref><ref>{{cite report |url=https://apps.dtic.mil/sti/pdfs/ADA115440.pdf |title=A History of the ARPANET: The First Decade |date=1 April 1981 |publisher=Bolt, Beranek & Newman Inc. |pages=13, 53 of 183 |quote=Aside from the technical problems of interconnecting computers with communications circuits, the notion of computer networks had been considered in a number of places from a theoretical point of view. Of particular note was work done by Paul Baran and others at the Rand Corporation in a study "On Distributed Communications" in the early 1960's. Also of note was work done by Donald Davies and others at the National Physical Laboratory in England in the mid-1960's. ... Another early major network development which affected development of the ARPANET was undertaken at the National Physical Laboratory in Middlesex, England, under the leadership of D. W. Davies. |archive-url=https://web.archive.org/web/20121201013642/http://www.dtic.mil/cgi-bin/GetTRDoc?Location=U2&doc=GetTRDoc.pdf&AD=ADA115440 |archive-date=1 December 2012 |url-status=live}}</ref>

Davies built a local-area network with a single packet switch and worked on the simulation of wide-area [[datagram]] networks.<ref name="Hempstead20052">{{cite book|author1=C. Hempstead|url=https://books.google.com/books?id=2ZCNAgAAQBAJ&pg=PA574|title=Encyclopedia of 20th-Century Technology|author2=W. Worthington|date=2005|publisher=[[Routledge]]|isbn=9781135455514|quote=Simulation work on packet networks was also undertaken by the NPL group.}}</ref><ref name=":8">{{Cite thesis |last=Clarke |first=Peter |title=Packet and circuit-switched data networks |date=1982 |degree=PhD |publisher=Department of Electrical Engineering, Imperial College of Science and Technology, University of London |url=https://spiral.imperial.ac.uk/bitstream/10044/1/35864/2/Clarke-PN-1982-PhD-Thesis.pdf}} "As well as the packet switched network actually built at NPL for communication between their local computing facilities, some simulation experiments have been performed on larger networks. A summary of this work is reported in [69]. The work was carried out to investigate networks of a size capable of providing data communications facilities to most of the U.K. ... Experiments were then carried out using a method of flow control devised by Davies [70] called 'isarithmic' flow control. ... The simulation work carried out at NPL has, in many respects, been more realistic than most of the ARPA network theoretical studies."</ref><ref name="Pelkey">{{cite book |last=Pelkey |first=James |url=https://www.historyofcomputercommunications.info/section/8.3/cyclades-network-and-louis-pouzin-1971-1972/ |title=Entrepreneurial Capitalism and Innovation: A History of Computer Communications 1968-1988 |chapter=8.3 CYCLADES Network and Louis Pouzin 1971-1972 |quote=Pouzin returned to his task of designing a simpler packet switching network than Arpanet. ... [Davies] had done some simulation of [wide-area] datagram networks, although he had not built any, and it looked technically viable. |access-date=2021-11-21 |archive-url=https://web.archive.org/web/20210617093154/https://www.historyofcomputercommunications.info/section/8.3/cyclades-network-and-louis-pouzin-1971-1972/ |archive-date=2021-06-17 |url-status=dead}}</ref> Building on these ideas, and seeking to improve on the implementation in the ARPANET,<ref name="Pelkey" /> [[Louis Pouzin|Louis Pouzin's]] [[CYCLADES]] network was the first to implement datagrams in a wide-area network and make the [[host (network)|hosts]] responsible for the reliable delivery of data, rather than this being a centralized service of the network itself.<ref name="Bennett2009" /> Concepts implemented in this network feature in [[TCP/IP]] architecture.<ref name=":0">{{Cite book |last=Green |first=Lelia |url=https://www.worldcat.org/title/504280762 |title=The internet: an introduction to new media |date=2010 |publisher=Berg |isbn=978-1-84788-299-8 |series=Berg new media series |page=31 |oclc=504280762 |quote=The original ARPANET design had made data integrity part of the IMP's store-and-forward role, but Cyclades end-to-end protocol greatly simplified the packet switching operations of the network. ... The idea was to adopt several principles from Cyclades and invert the ARPANET model to minimise international differences.}}</ref><ref>{{cite news|date=13 December 2013|title=The internet's fifth man|work=Economist|url=https://www.economist.com/news/technology-quarterly/21590765-louis-pouzin-helped-create-internet-now-he-campaigning-ensure-its|quote=In the early 1970s Mr Pouzin created an innovative data network that linked locations in France, Italy and Britain. Its simplicity and efficiency pointed the way to a network that could connect not just dozens of machines, but millions of them. It captured the imagination of Dr Cerf and Dr Kahn, who included aspects of its design in the protocols that now power the internet.|accessdate=11 September 2017}}</ref>

==Applications==
===ARPANET===
The ARPANET demonstrated several important aspects of the end-to-end principle.
;Packet switching pushes some logical functions toward the communication endpoints
:If the basic premise of a distributed network is packet switching, then functions such as reordering and duplicate detection inevitably have to be implemented at the logical endpoints of such a network. Consequently, the ARPANET featured two distinct levels of functionality:
:# a lower level concerned with transporting data packets between neighboring network nodes (called [[Interface Message Processor]]s or IMPs), and
:# a higher level concerned with various end-to-end aspects of the data transmission.{{efn|In accordance with the ARPANET RFQ<ref name="RFQ1968" /> (pp. 47 f.) the ARPANET conceptually separated certain functions. As BBN points out in a 1977 paper:<ref name="BBN1977" /> "[T]he ARPA Network implementation uses the technique of breaking messages into packets to minimize the delay seen for long transmissions over many hops. The ARPA Network implementation also allows several messages to be in transit simultaneously between a given pair of Hosts. However, the several messages and the packets within the messages may arrive at the destination IMP out of order, and in the event of a broken IMP or line, there may be duplicates. The task of the ARPA Network source-to-destination transmission procedure is to reorder packets and messages at their destination, to cull duplicates, and after all the packets of a message have arrived, pass the message on to the destination Host and return an end-to-end acknowledgment. (p. 284)."}}
:Dave Clark, one of the authors of the end-to-end principle paper, concludes: "The discovery of packets is not a consequence of the end-to-end argument. It is the success of packets that make the end-to-end argument relevant."<ref name="Clark2007" />{{rp|slide 31}}

;No arbitrarily reliable data transfer without end-to-end acknowledgment and retransmission mechanisms
: The ARPANET was designed to provide reliable data transport between any two endpoints of the network{{snd}} much like a simple I/O channel between a computer and a nearby peripheral device.{{efn|This requirement was spelled out in the ARPANET [[request for quotation|RFQ]], "From the point of view of the ARPA contractors as users of the network, the communication subnet is a self-contained facility whose software and hardware is maintained by the network contractor. In designing Interconnection Software we should only need to use the I/0 conventions for moving data into and out of the subnet and not otherwise be involved in the details of subnet operation. Specifically, error checking, fault detection, message switching, fault recovery, line switching, carrier failures and carrier quality assessment, as required to guarantee reliable network performance, are the sole responsibility of the network contractor."<ref name="RFQ1968" />{{rp|25}}}} In order to remedy any potential failures of packet transmission normal ARPANET messages were handed from one node to the next node with a positive acknowledgment and retransmission scheme; after a successful handover they were then discarded,{{efn|Notes Walden in a 1972 paper, "Each IMP holds on to a packet until it gets a positive acknowledgment from the next IMP down the line that the packet has been properly received. If it gets the acknowledgment, all is well; the IMP knows that the next IMP now has responsibility for the packet and the transmitting IMP can discard its copy of the packet."<ref name="Walden1972" />{{rp|11}}}} no source-to-destination re-transmission in case of [[packet loss]] was catered for. However, in spite of significant efforts, perfect reliability as envisaged in the initial ARPANET specification turned out to be impossible to provide{{snd}}a reality that became increasingly obvious once the ARPANET grew well beyond its initial four-node topology.{{efn|By 1973, [[BBN Technologies|BBN]] acknowledged that the initial aim of perfect reliability inside the ARPANET was not achievable, "Initially, it was thought that the only components in the network design that were prone to errors were the communications circuits, and the modem interfaces in the IMPs are equipped with a CRC checksum to detect 'almost all' such errors. The rest of the system, including Host interfaces, IMP processors, memories, and interfaces, were all considered to be error-free. We have had to re-evaluate this position in the light of our experience.<ref name="BBN1973" />{{rp|1}} In fact, as Metcalfe summarizes by 1973, "there have been enough bits in error in the ARPANET to fill this quota [one undetected transmission bit error per year] for centuries."<ref name="Met1973" />{{rp|7–28}} See also BBN Report 2816<ref name="BBN1974" />{{rp|10 ff}} for additional elaboration about the experiences gained in the first years of operating the ARPANET.}} The ARPANET thus provided a strong case for the inherent limits of network-based hop-by-hop reliability mechanisms in pursuit of true end-to-end reliability.{{efn|Incidentally, the ARPANET also provides a good case for the trade-offs between the cost of end-to-end reliability mechanisms versus the benefits to be obtained thus. True end-to-end reliability mechanisms would have been prohibitively costly at the time, given that the specification held that there could be up to 8 host-level messages in flight at the same time between two endpoints, each having a maximum of more than 8000 bits. The amount of memory that would have been required to keep copies of all those data for possible retransmission in case no acknowledgment came from the destination IMP was too expensive to be worthwhile. As for host-based end-to-end reliability mechanisms{{snd}}those would have added considerable complexity to the common host-level protocol ([[Network Control Protocol (ARPANET)|Host-Host Protocol]]). While the desirability of host-host reliability mechanisms was articulated in {{IETF RFC|1}}, after some discussion they were dispensed with (although higher-level protocols or applications were, of course, free to implement such mechanisms themselves). For a recount of the debate at the time see Bärwolff 2010,<ref name="Bae2010" /> pp. 56-58 and the notes therein, especially notes 151 and 163.}}

;Trade-off between reliability, latency, and throughput
: The pursuit of perfect reliability may hurt other relevant parameters of a data transmission{{snd}}most importantly latency and throughput. This is particularly important for applications that value predictable throughput and low latency over reliability{{snd}}the classic example being interactive real-time voice applications. This [[use case]] was catered for in the ARPANET by providing a raw message service that dispensed with various reliability measures so as to provide faster and lower latency data transmission service to the end hosts.{{efn|Early experiments with packet voice date back to 1971, and by 1972 more formal ARPA research on the subject commenced. As documented in {{IETF RFC|660}} (p. 2),<ref name="Walden1974" /> in 1974 BBN introduced the raw message service (Raw Message Interface, RMI) to the ARPANET, primarily in order to allow hosts to experiment with packet voice applications, but also acknowledging the use of such facility in view of possibly internetwork communication (cf. a BBN Report 2913<ref name="BBN1974b" /> at pp. 55 f.). See also Bärwolff 2010,<ref name="Bae2010" /> pp. 80-84 and the copious notes therein.}}

===TCP/IP===
[[Internet Protocol]] (IP) is a [[connectionless]] datagram service with [[best-effort delivery|no delivery guarantees]]. On the Internet, IP is used for nearly all communications. End-to-end acknowledgment and retransmission is the responsibility of the connection-oriented [[Transmission Control Protocol]] (TCP) which sits on top of IP.  The functional split between IP and TCP exemplifies the proper application of the end-to-end principle to transport protocol design.

===File transfer===
An example of the end-to-end principle is that of an arbitrarily reliable file transfer between two endpoints in a distributed network of a varying, nontrivial size:<ref name="SRC1984" />  The only way two endpoints can obtain a completely reliable transfer is by transmitting and acknowledging a [[checksum]] for the entire data stream; in such a setting, lesser checksum and acknowledgment ([[acknowledgement (data networks)|ACK]]/NACK) protocols are justified only for the purpose of optimizing performance{{snd}}they are useful to the vast majority of clients, but are not enough to fulfill the reliability requirement of this particular application. A thorough checksum is hence best done at the endpoints, and the network maintains a relatively low level of complexity and reasonable performance for all clients.<ref name="SRC1984" />

==Limitations==
The most important limitation of the end-to-end principle is that its basic premise, placing functions in the application endpoints rather than in the intermediary nodes, is not trivial to implement. 

An example of the limitations of the end-to-end principle exists in mobile devices with [[mobile IPv6]].<ref>{{Cite IETF|rfc=3724|author1=J. Kempf|author2=R. Austein|date=March 2004|title=The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Archichecture|publisher=Network Working Group, [[IETF]]}}</ref> Pushing service-specific complexity to the endpoints can cause issues with mobile devices if the device has unreliable access to network channels.<ref>{{Cite web|url=http://www.winlab.rutgers.edu/docs/focus/CNF/protocol%20architecture.html|title=CNF Protocol Architecture|website=Focus Projects|publisher=Winlab, Rutgers University|access-date=May 23, 2016|archive-date=June 23, 2016|archive-url=https://web.archive.org/web/20160623210856/http://www.winlab.rutgers.edu/docs/focus/CNF/protocol%20architecture.html|url-status=dead}}</ref>

Further problems can be seen with a decrease in network transparency from the addition of [[network address translation]] (NAT), which [[IPv4]] relies on to combat [[IPv4 address exhaustion|address exhaustion]].<ref>{{Cite news|url=https://www.bbc.com/news/technology-19600718|title=Europe hits old internet address limits|last=Ward|first=Mark|date=2012-09-14|work=BBC News|access-date=2017-02-28|language=en-GB}}</ref> With the introduction of [[IPv6]], users once again have unique identifiers, allowing for true end-to-end connectivity. Unique identifiers may be based on a [[MAC address|physical address]], or can be generated randomly by the host.<ref>{{Cite web|url=http://ftp.cuhk.edu.hk/pub/doc/ipng/html/ipv6-address-privacy.html|title=Statement on IPv6 Address Privacy|last=Steve Deering & Bob Hinden|first=Co-Chairs of the IETF's IP Next Generation Working Group|date=November 6, 1999|access-date=2017-02-28}}</ref>

The end-to-end principle advocates pushing coordination-related functionality ever higher, ultimately into the application layer. The premise is that application-level information enables flexible coordination between the application endpoints and yields better performance because the coordination would be exactly what is needed.  This leads to the idea of modeling each application via its own application-specific protocol that supports the desired coordination between its endpoints while assuming only a simple lower-layer communication service.  Broadly, this idea is known as application semantics (meaning).

Multiagent systems offers approaches based on application semantics that enable conveniently implementing distributed applications without requiring message ordering and delivery guarantees from the underlying communication services.  A basic idea in these approaches is to model the coordination between application endpoints via an information protocol<ref>{{cite web|title= Information-Driven Interaction-Oriented Programming: BSPL, the Blindingly Simple Protocol Language|url=http://www.csc.ncsu.edu/faculty/mpsingh/papers/mas/AAMAS-11-IBIOP.pdf |first1=Munindar P. |last1=Singh |publisher=Department of Computer Science, North Carolina State University |accessdate=24 April 2013 |url-status=dead |archive-url=https://web.archive.org/web/20150607040221/http://www.csc.ncsu.edu/faculty/mpsingh/papers/mas/AAMAS-11-IBIOP.pdf |archive-date= Jun 7, 2015 }}</ref> and then implement the endpoints (agents) based on the protocol.  Information protocols can be enacted over lossy, unordered communication services. A middleware based on information protocols and the associated programming model abstracts away message receptions from the underlying network and enables endpoint programmers to focus on the [[business logic]] for sending messages.

==See also==
*{{annotated link|End-to-end encryption}}
*{{annotated link|History of the Internet}}
*{{annotated link|Peer-to-peer}}
*{{annotated link|Protocol Wars}}

==Notes==
{{Notelist}}

==References==
{{Reflist|refs=
<ref name="Bar1964">Baran, P. (1964). "On Distributed Communications Networks". In: IEEE Transactions on Communications 12.1, pp. 1–9.</ref>
<ref name="Bae2010">Bärwolff, M. (2010). "End-to-End Arguments in the Internet: Principles, Practices, and Theory". Self-published online and via Createspace/Amazon ([http://xn--brwolff-5wa.de/publications/2010-10-PhD-thesis.html PDF, errata, etc.])</ref>
<ref name="BBN1974">Bolt, Beranek and Newman Inc. (1974). Interface Message Processors for the Arpa Computer Network. BBN Report 2816. Quarterly Technical Report No.5, 1 January 1974 to 31 March 1974. Bolt, Beranek and Newman Inc. (BBN). ([http://xn--brwolff-5wa.de/public/BBN-1974--Interface-Message-Processors-for-the-ARPA-Computer-Network--Report-2816--Quarterly-Technical-Report-5.pdf Private copy, courtesy of BBN]).</ref>
<ref name="BBN1977">McQuillan, J. M. and D. C. Walden (1977). "The ARPA Network Design Decisions". In: Computer Networks 1.5, pp. 243–289. ([http://www.walden-family.com/public/whole-paper.pdf Online copy]). Based on a Crowther et al. (1975) paper, which is based on BBN Report 2918, which in turn is an extract from BBN Report 2913, both from 1974.</ref>
<ref name="BC2001">Blumenthal, M. S. and D. D. Clark (2001). "Rethinking the Design of the Internet: The End-to-End Arguments vs. the Brave World". In: ACM Transactions on Internet Technology 1.1, pp. 70–109. ([https://dspace.mit.edu/bitstream/handle/1721.1/1519/TPRC_Clark_Blumenthal.pdf?sequence=1&origin=publication_detail Online pre-publication version]).</ref>
<ref name="Clark1978">Clark, D. D., K. T. Pogran, and D. P. Reed (1978). “An Introduction to Local Area Networks”. In: Proceedings of the IEEE 66.11, pp. 1497–1517.</ref>
<ref name="Clark2007">Clark, D. D. (2007). Application Design and the End-to-End Arguments. MIT Communications Futures Program Bi-Annual Meeting. Philadelphia, PA. May 30–31, 2007. Presentation slides. ([http://cfp.mit.edu/events/may07/presentations/CLARK%20Application%20Design.ppt Online copy]).</ref>
<ref name="Dav1967">Davies, D. W., K. A. Bartlett, R. A. Scantlebury, and P. T. Wilkinson (1967). "A Digital Communication Network for Computers Giving Rapid Response at Remote Terminals". In: SOSP '67: Proceedings of the First ACM Symposium on Operating System Principles. Gatlinburg, TN. October 1–4, 1967. New York, NY: ACM, pp. 2.1–2.17.</ref>
<ref name="BBN1973">McQuillan, J. M. (1973). Software Checksumming in the IMP and Network Reliability. {{IETF RFC|528}}. Historic. NWG.</ref>
<ref name="RFQ1968">Scheblik, T. J., D. B. Dawkins, and Advanced Research Projects Agency (1968). RFQ for ARPA Computer Network. Request for Quotations. Advanced Research Projects Agency (ARPA), Department of Defense (DoD). ([http://www.cs.utexas.edu/users/chris/DIGITAL_ARCHIVE/ARPANET/RFQ-ARPA-IMP.pdf Online copy] {{webarchive|url=https://web.archive.org/web/20110815020022/http://www.cs.utexas.edu/users/chris/DIGITAL_ARCHIVE/ARPANET/RFQ-ARPA-IMP.pdf |date=2011-08-15 }}).</ref>
<ref name="SRC1981">Saltzer, J. H., D. P. Reed, and D. D. Clark (1981) "End-to-End Arguments in System Design". In: Proceedings of the Second International Conference on Distributed Computing Systems. Paris, France. April 8–10, 1981. IEEE Computer Society, pp. 509-512.</ref>
<ref name="SRC1984">{{Cite Q | Q56503280 | access-date = 2022-04-05}} <!-- Saltzer 1984 --></ref>
<ref name="Sunshine1975">Sunshine, C. A. (1975). Issues in Communication Protocol Design &ndash; Formal Correctness. Draft. INWG Protocol Note 5. IFIP WG 6.1 (INWG). ([http://xn--brwolff-5wa.de/public/Sunshine-1975-Issues-in-Communication-Protocol-Design--Formal-Correctness--INWG-Note-5.pdf Copy from CBI]).</ref>
<ref name="Walden1972">Walden, D. C. (1972). "The Interface Message Processor, Its Algorithms, and Their Implementation". In: AFCET Journées d’Études: Réseaux de Calculateurs (AFCET Workshop on Computer Networks). Paris, France. May 25–26, 1972. Association Française pour la Cybernétique Économique et Technique (AFCET). ([http://www.walden-family.com/public/1972-afcet-paris.pdf Online copy]).</ref>
<ref name="Met1973">Metcalfe, R. M. (1973). "Packet Communication". PhD thesis. Cambridge, MA: Harvard University. [http://publications.csail.mit.edu/lcs/pubs/pdf/MIT-LCS-TR-114.pdf Online copy] (revised edition, published as MIT Laboratory for Computer Science Technical Report 114). Mostly written at MIT Project MAC and Xerox PARC.</ref>
<ref name="BBN1974b">BBN (1974). Interface Message Processors for the Arpa Computer Network. BBN Report 2913. Quarterly Technical Report No. 7, 1 July 1974 to 30 September 1974. Bolt, Beranek and Newman Inc. (BBN).</ref>
<ref name="Walden1974">Walden, D. C. (1974) Some Changes to the IMP and the IMP/Host Interface. {{IETF RFC|660}}. Historic. NWG.</ref>
<ref name="SAL1980">Saltzer, J. H. (1980). End-to-End Arguments in System Design. Request for Comments No. 185, MIT Laboratory for Computer Science, Computer Systems Research Division. ([http://web.mit.edu/Saltzer/www/publications/rfc/csr-rfc-185.pdf Online copy]).</ref>
}}

[[Category:Internet architecture]]
[[Category:Net neutrality]]
[[Category:Network architecture]]
[[Category:Programming paradigms]]