Editing End-to-end principle (section)

===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.}}