एंड-टू-एंड सिद्धांत

From Vigyanwiki

एंड-टू-एंड सिद्धांत संगणक संजाल िंग में एक डिजाइन ढांचा है। इस सिद्धांत के अनुसार नेटवर्क योजना और डिजाइन में, कुछ एप्लिकेशन-विशिष्ट सुविधाओं की गारंटी, जैसे कि विश्वसनीयता और सुरक्षा, के लिए आवश्यक है कि वे नेटवर्क के संचार एंड नोड में रहें। गेटवे (दूरसंचार) और राउटर (कंप्यूटिंग) जैसे मध्यवर्ती नोड, जो नेटवर्क स्थापित करने के लिए उपलब्ध हैं, दक्षता में संशोधन के लिए इन्हें प्रयुक्त कर सकते हैं लेकिन एंड-टू-एंड शुद्धता की गारंटी नहीं दे सकते।

जिसे बाद में एंड-टू-एंड सिद्धांत कहा जाएगा उसका सार 1960 के दशक में पैकेट-स्विच्ड नेटवर्क पर पॉल बरन और डोनाल्ड डेविस के काम में निहित था। लुई पॉज़िन ने 1970 के दशक में साइक्लेडेस नेटवर्क में एंड-टू-एंड रणनीति के उपयोग का बीड़ा उठाया।[1] इस सिद्धांत को पहली बार 1981 में जेरोम एच. साल्टज़र, डेविड पी. रीड और डेविड डी. क्लार्क द्वारा स्पष्ट रूप से व्यक्त किया गया था।[2][lower-alpha 1] एंड-टू-एंड सिद्धांत का अर्थ इसकी प्रारंभिक अभिव्यक्ति के बाद से निरंतर पुनर्व्याख्या की गई है। इसके अतिरिक्त, एंड-टू-एंड सिद्धांत के उल्लेखनीय योग 1981 के साल्टज़र, रीड और क्लार्क पेपर से पहले पाए जा सकते हैं।[3]

सिद्धांत का एक मूल आधार यह है कि संचार उपप्रणाली में अंतिम अनुप्रयोग के लिए आवश्यक कुछ विशेषताओं को जोड़ने से होने वाला भुगतान शीघ्र ही कम हो जाता है। अंतिम होस्टों को इन कार्यों को शुद्धता के लिए प्रयुक्त करना होगा।[lower-alpha 2] किसी विशिष्ट फ़ंक्शन को प्रयुक्त करने पर कुछ संसाधन दंड लगते हैं चाहे फ़ंक्शन का उपयोग किया जाता है या नहीं, और नेटवर्क में एक विशिष्ट फ़ंक्शन को प्रयुक्त करने से ये दंड सभी क्लाइंट पर जुड़ जाते हैं, तथापि उन्हें फ़ंक्शन की आवश्यकता हो या नहीं।

अवधारणा

एंड-टू-एंड सिद्धांत के अनुसार, नेटवर्क केवल टर्मिनलों को सर्वोत्तम प्रयास कनेक्शन प्रदान करने के लिए जिम्मेदार है। विश्वसनीयता और सुरक्षा जैसी विशेषताएं टर्मिनलों पर स्थित तंत्र और प्रोटोकॉल द्वारा प्रदान की जानी चाहिए।

एंड-टू-एंड सिद्धांत के पीछे मूलभूत धारणा यह है कि दो प्रक्रियाओं (कंप्यूटिंग) के लिए कुछ संचार माध्यमों के माध्यम से एक दूसरे के साथ संचार करना, उस माध्यम से प्राप्त विश्वसनीयता को प्रक्रियाओं की विश्वसनीयता आवश्यकताओं के साथ पूरी तरह से संरेखित करने की उम्मीद नहीं की जा सकती है। विशेष रूप से, गैर-तुच्छ आकार के नेटवर्क द्वारा अलग की गई संचार प्रक्रियाओं की बहुत उच्च-विश्वसनीयता आवश्यकताओं को पूरा करना या उससे अधिक होना सकारात्मक एंड-टू-एंड पावती और रिट्रांसमिशन (पुन: प्रसारण के साथ सकारात्मक पावती के रूप में संदर्भित) द्वारा विश्वसनीयता की आवश्यक डिग्री प्राप्त करने की तुलना में अधिक बहुमूल्य है। या स्वचालित दोहराने का अनुरोध)।[lower-alpha 3] दूसरी विधि से कहें तो, मध्यस्थ नोड्स के अतिरिक्त नेटवर्क के अंतिम होस्टों में तंत्र द्वारा एक निश्चित मार्जिन से परे विश्वसनीयता प्राप्त करना कहीं अधिक आसान है,[lower-alpha 4] विशेष रूप से जब बाद वाले नियंत्रण से बाहर हैं, और पूर्व के प्रति जवाबदेह नहीं हैं।[lower-alpha 5] अनंत पुनर्प्रयास के साथ सकारात्मक एंड-टू-एंड पावती किसी भी नेटवर्क से मनमाने ढंग से उच्च विश्वसनीयता प्राप्त कर सकती है, जिसमें डेटा को एक छोर से दूसरे छोर तक सफलतापूर्वक प्रसारित करने की शून्य से अधिक संभावना होती है।[lower-alpha 6]

एंड-टू-एंड सिद्धांत एंड-टू-एंड त्रुटि नियंत्रण और संशोधन, और सुरक्षा से परे कार्यों तक विस्तारित नहीं होता है। उदाहरण के लिए, विलंबता (इंजीनियरिंग) और थ्रूपुट जैसे संचार मापदंडों के लिए कोई सीधा एंड-टू-एंड तर्क नहीं दिया जा सकता है। 2001 के एक पेपर में, ब्लुमेंथल और क्लार्क ने नोट किया: [एफ] प्रारंभ से, अंत-से-अंत तर्क उन आवश्यकताओं के इर्द-गिर्द घूमते थे जिन्हें अंत बिंदुओं पर सही ढंग से प्रयुक्त किया जा सकता था; यदि नेटवर्क के अंदर कार्यान्वयन आवश्यकता को पूरा करने की एकमात्र विधि है, तो पहले स्थान पर एंड-टू-एंड तर्क उचित नहीं है।[7]: 80 

एंड-टू-एंड सिद्धांत निकटता से संबंधित है, और कभी-कभी शुद्ध तटस्थता के सिद्धांत के प्रत्यक्ष अग्रदूत के रूप में देखा जाता है।[8]


इतिहास

1960 के दशक में, पॉल बरन और डोनाल्ड डेविस ने नेटवर्किंग के अपने पूर्व-एआरपीएनेट विस्तार में, विश्वसनीयता के बारे में संक्षिप्त टिप्पणी की जो बाद के एंड-टू-एंड सिद्धांत के सार को पकड़ती है। 1964 के बरन पेपर से उद्धृत करने के लिए, विश्वसनीयता और कच्ची त्रुटि दर गौण हैं। नेटवर्क को वैसे भी भारी नुकसान की उम्मीद के साथ बनाया जाना चाहिए। शक्तिशाली त्रुटि हटाने की विधियाँ उपलब्ध हैं।[9]: 5  इसी तरह, डेविस एंड-टू-एंड एरर नियंत्रण पर नोट करता है, यह सोचा जाता है कि नेटवर्क के सभी उपयोगकर्ता खुद को किसी प्रकार का एरर नियंत्रण प्रदान करेंगे और यह बिना किसी कठिनाई के लापता पैकेट को दिखाने के लिए बनाया जा सकता है। इस वजह से, पैकेटों की हानि, यदि यह पर्याप्त रूप से विरल है, को सहन किया जा सकता है।[10]: 2.3 

एआरपीएनेट पहला बड़े पैमाने का सामान्य-उद्देश्य वाला पैकेट स्विचिंग नेटवर्क था – बरन और डेविस द्वारा पूर्व में स्पर्श की गई कई मूलभूत धारणाओं को प्रयुक्त करना।

डेविस ने आंकड़ारेख नेटवर्क के अनुकरण पर काम किया था।[11][12] इस विचार पर आधारित, लुइस पॉज़िन|लुईस पौज़िन का साइक्लेड्स नेटवर्क सबसे पहले होस्ट (नेटवर्क) को डेटा के विश्वसनीय वितरण के लिए ज़िम्मेदार बनाता था, अतिरिक्त इसके कि यह स्वयं नेटवर्क की एक केंद्रीकृत सेवा थी।[1]इस नेटवर्क में प्रयुक्त अवधारणाओं ने टीसीपी/आईपी आर्किटेक्चर को प्रभावित किया।[13]


अनुप्रयोग

एआरपीएनेट

एआरपीएनेट ने एंड-टू-एंड सिद्धांत के कई महत्वपूर्ण पहलुओं का प्रदर्शन किया।

पैकेट स्विचिंग कुछ तार्किक कार्यों को संचार समापन बिंदुओं की ओर धकेलती है
यदि एक वितरित नेटवर्क का मूल आधार पैकेट स्विचिंग है, तो ऐसे नेटवर्क के तार्किक समापन बिंदुओं पर अनिवार्य रूप से पुन: क्रमांकन और डुप्लिकेट डिटेक्शन जैसे कार्यों को प्रयुक्त किया जाना है। नतीजतन, एआरपीएनेट ने कार्यक्षमता के दो अलग-अलग स्तरों को प्रदर्शित किया:
  1. पड़ोसी नेटवर्क नोड्स (इंटरफ़ेस संदेश प्रोसेसर या IMPs कहा जाता है) के बीच डेटा पैकेट के परिवहन से संबंधित एक निचला स्तर, और
  2. डेटा ट्रांसमिशन के विभिन्न एंड-टू-एंड पहलुओं से संबंधित एक उच्च स्तर।[lower-alpha 7]
एंड-टू-एंड प्रिंसिपल पेपर के लेखकों में से एक, डेव क्लार्क ने निष्कर्ष निकाला: पैकेट की खोज एंड-टू-एंड तर्क का परिणाम नहीं है। यह पैकेट्स की सफलता है जो एंड-टू-एंड तर्क को प्रासंगिक बनाती है।[16]: slide 31 

एंड-टू-एंड पावती और रीट्रांसमिशन तंत्र के बिना कोई मनमाने ढंग से विश्वसनीय डेटा ट्रांसफर नहीं

एआरपीएनेट को नेटवर्क के किन्हीं दो समापन बिंदुओं के बीच विश्वसनीय डेटा परिवहन प्रदान करने के लिए डिज़ाइन किया गया था – कंप्यूटर और आस-पास के परिधीय उपकरण के बीच एक साधारण I/O चैनल की तरह।[lower-alpha 8] पैकेट ट्रांसमिशन की किसी भी संभावित विफलता को दूर करने के लिए सामान्य एआरपीएनेट संदेशों को सकारात्मक पावती और पुन: प्रसारण योजना के साथ एक नोड से अगले नोड तक भेजा गया था; एक सफल हैंडओवर के बाद उन्हें फिर से छोड़ दिया गया,[lower-alpha 9] पैकेट खो जाने की स्थिति में स्रोत-से-गंतव्य पुन: प्रसारण की व्यवस्था नहीं की गई थी। चूँकि, महत्वपूर्ण प्रयासों के अतिरिक्त, प्रारंभिक एआरपीएनेट विनिर्देशन में परिकल्पित पूर्ण विश्वसनीयता प्रदान करना असंभव साबित हुआ – एक वास्तविकता जो तेजी से स्पष्ट हो गई जब एआरपीएनेट अपने प्रारंभिक चार-नोड टोपोलॉजी से अत्यधिक आगे बढ़ गया।[lower-alpha 10] इस प्रकार एआरपीएनेट ने वास्तविक एंड-टू-एंड विश्वसनीयता की खोज में नेटवर्क-आधारित हॉप-बाय-हॉप विश्वसनीयता तंत्र की अंतर्निहित सीमाओं के लिए एक कठोर स्थिति प्रदान की थी।[lower-alpha 11]
विश्वसनीयता, विलंबता और थ्रूपुट के बीच व्यापार बंद
पूर्ण विश्वसनीयता की खोज डेटा ट्रांसमिशन के अन्य प्रासंगिक मापदंडों को नुकसान पहुंचा सकती है – सबसे महत्वपूर्ण विलंबता और थ्रूपुट। यह उन अनुप्रयोगों के लिए विशेष रूप से महत्वपूर्ण है जो अनुमानित थ्रूपुट और विश्वसनीयता पर कम विलंबता को महत्व देते हैं – इंटरैक्टिव रीयल-टाइम वॉयस एप्लिकेशन इसका उत्कृष्ट उदाहरण है। इस उपयोग की स्थिति को एआरपीएनेट में एक कच्ची संदेश सेवा प्रदान करके पूरा किया गया था, जो विभिन्न विश्वसनीयता उपायों से दूर थी जिससे अंतिम होस्टों को तेज़ और कम विलंबता डेटा ट्रांसमिशन सेवा प्रदान की जा सके।[lower-alpha 12]

टीसीपी/आईपी

इंटरनेट प्रोटोकॉल (आईपी) सर्वोत्तम प्रयास वितरण के साथ एक संयोजन रहित डेटाग्राम सेवा है। इंटरनेट पर, IP का उपयोग लगभग सभी संचारों के लिए किया जाता है। एंड-टू-एंड पावती और पुन: प्रसारण कनेक्शन-उन्मुख प्रसारण नियंत्रण प्रोटोकॉल (टीसीपी) की जिम्मेदारी है जो आईपी के शीर्ष पर बैठता है। आईपी ​​​​और टीसीपी के बीच कार्यात्मक विभाजन प्रोटोकॉल डिजाइन परिवहन के लिए एंड-टू-एंड सिद्धांत के उचित अनुप्रयोग का उदाहरण देता है।

फाइल ट्रांसफर

एंड-टू-एंड सिद्धांत का एक उदाहरण अलग-अलग, गैर-तुच्छ आकार के वितरित नेटवर्क में दो एंडपॉइंट्स के बीच मनमाने ढंग से विश्वसनीय फ़ाइल स्थानांतरण का है:[3] संपूर्ण डेटा स्ट्रीम के लिए एक अंततः, को प्रेषित और स्वीकार करके दो समापन बिंदु पूरी तरह से विश्वसनीय हस्तांतरण प्राप्त कर सकते हैं; ऐसी सेटिंग में, कम चेकसम और पावती (पावती (डेटा नेटवर्क)/NACK) प्रोटोकॉल केवल प्रदर्शन को अनुकूलित करने के उद्देश्य से उचित हैं – वे अधिकांश ग्राहकों के लिए उपयोगी हैं, लेकिन इस विशेष एप्लिकेशन की विश्वसनीयता आवश्यकता को पूरा करने के लिए पर्याप्त नहीं हैं। एक संपूर्ण चेकसम इसलिए अंतिम बिंदुओं पर सबसे अच्छा किया जाता है, और नेटवर्क सभी ग्राहकों के लिए अपेक्षाकृत कम स्तर की जटिलता और उचित प्रदर्शन बनाए रखता है।[3]


सीमाएं

एंड-टू-एंड सिद्धांत की सबसे महत्वपूर्ण सीमा यह है कि इसका मूल आधार, मध्यस्थ नोड्स के अतिरिक्त एप्लिकेशन एंडपॉइंट्स में फ़ंक्शन रखना, प्रयुक्त करने के लिए तुच्छ नहीं है।

एंड-टू-एंड सिद्धांत की सीमाओं का एक उदाहरण मोबाइल उपकरणों में उपलब्ध है, उदाहरण के लिए मोबाइल आईपीवी6 के साथ।[24] सेवा-विशिष्ट जटिलता को एंडपॉइंट्स पर धकेलने से मोबाइल उपकरणों के साथ समस्याएँ हो सकती हैं यदि डिवाइस के पास नेटवर्क चैनलों तक अविश्वसनीय पहुँच है।[25]

आगे की समस्याओं को नेटवर्क एड्रेस ट्रांसलेशन (एनएटी) के अतिरिक्त नेटवर्क पारदर्शिता में कमी के साथ देखा जा सकता है, जो आईपीवी4 आईपीवी4 एड्रेस थकावट का मुकाबला करने के लिए निर्भर करता है।[26] आईपीवी6 की प्रारंभ के साथ, उपयोगकर्ताओं के पास एक बार फिर अद्वितीय पहचानकर्ता होते हैं, जो सही एंड-टू-एंड कनेक्टिविटी की अनुमति देते हैं। विशिष्ट पहचानकर्ता मैक पते पर आधारित हो सकते हैं, या होस्ट द्वारा यादृच्छिक रूप से उत्पन्न किए जा सकते हैं।[27]


यह भी देखें

टिप्पणियाँ

  1. The 1981 paper[2] was published in ACM's TOCS in an updated version in 1984.[3][4]
  2. The full quote from the Saltzer, Reed, Clark paper states:[3] "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).
  3. In fact, even in local area networks there is a non-zero probability of communication failure – "attention to reliability at higher levels is required regardless of the control strategy of the network".[5]
  4. 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:[3] "Clearly, some effort at the lower levels to improve network reliability can have a significant effect on application performance. (p. 281)."
  5. 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.
  6. More precisely:[6] "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).
  7. In accordance with the ARPANET RFQ[14] (pp. 47 f.) the ARPANET conceptually separated certain functions. As BBN points out in a 1977 paper:[15] "[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)."
  8. This requirement was spelled out in the ARPANET 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."[14]: 25 
  9. 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."[17]: 11 
  10. By 1973, 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.[18]: 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."[19]: 7–28  See also BBN Report 2816[20]: 10 ff  for additional elaboration about the experiences gained in the first years of operating the ARPANET.
  11. 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. Note that 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 – those would have added considerable complexity to the common host level protocol (Host-Host Protocol). While the desirability of host-host reliability mechanisms was articulated in 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,[21] pp. 56-58 and the notes therein, especially notes 151 and 163.
  12. Early experiments with packet voice date back to 1971, and by 1972 more formal ARPA research on the subject commenced. As documented in RFC 660 (p. 2),[22] 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[23] at pp. 55 f.). See also Bärwolff 2010,[21] pp. 80-84 and the copious notes therein.


संदर्भ

  1. 1.0 1.1 Bennett, Richard (September 2009). "Designed for Change: End-to-End Arguments, Internet Innovation, and the Net Neutrality Debate" (PDF). Information Technology and Innovation Foundation. pp. 7, 11. Retrieved 11 September 2017.
  2. 2.0 2.1 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.
  3. 3.0 3.1 3.2 3.3 3.4 3.5 No label or title -- debug: Q56503280, Wikidata Q56503280 {{citation}}: |access-date= requires |url= (help)
  4. 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. (Online copy).
  5. 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.
  6. Sunshine, C. A. (1975). Issues in Communication Protocol Design – Formal Correctness. Draft. INWG Protocol Note 5. IFIP WG 6.1 (INWG). (Copy from CBI).
  7. 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. (Online pre-publication version).
  8. Alexis C. Madrigal & Adrienne LaFrance (25 Apr 2014). "Net Neutrality: A Guide to (and History of) a Contested Idea". The Atlantic. Retrieved 5 Jun 2014. This idea of net neutrality...[Lawrence Lessig] used to call the principle e2e, for end to end
  9. Baran, P. (1964). "On Distributed Communications Networks". In: IEEE Transactions on Communications 12.1, pp. 1–9.
  10. 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.
  11. C. Hempstead; W. Worthington (2005). Encyclopedia of 20th-Century Technology. Routledge. ISBN 9781135455514. Simulation work on packet networks was also undertaken by the NPL group.
  12. Pelkey, James. "6.3 CYCLADES Network and Louis Pouzin 1971-1972". Entrepreneurial Capitalism and Innovation: A History of Computer Communications 1968-1988. He had done some simulation of datagram networks, although he had not built any, and it looked technically viable.
  13. "इंटरनेट का पांचवां आदमी". Economist. 13 December 2013. Retrieved 11 September 2017. 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.
  14. 14.0 14.1 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). (Online copy Archived 2011-08-15 at the Wayback Machine).
  15. McQuillan, J. M. and D. C. Walden (1977). "The ARPA Network Design Decisions". In: Computer Networks 1.5, pp. 243–289. (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.
  16. 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. (Online copy).
  17. 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). (Online copy).
  18. McQuillan, J. M. (1973). Software Checksumming in the IMP and Network Reliability. RFC 528. Historic. NWG.
  19. Metcalfe, R. M. (1973). "Packet Communication". PhD thesis. Cambridge, MA: Harvard University. Online copy (revised edition, published as MIT Laboratory for Computer Science Technical Report 114). Mostly written at MIT Project MAC and Xerox PARC.
  20. 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). (Private copy, courtesy of BBN).
  21. 21.0 21.1 Bärwolff, M. (2010). "End-to-End Arguments in the Internet: Principles, Practices, and Theory". Self-published online and via Createspace/Amazon (PDF, errata, etc.)
  22. Walden, D. C. (1974) Some Changes to the IMP and the IMP/Host Interface. RFC 660. Historic. NWG.
  23. 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).
  24. J. Kempf; R. Austein (March 2004). The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Archichecture. Network Working Group, IETF. doi:10.17487/RFC3724. RFC 3724.
  25. "CNF प्रोटोकॉल आर्किटेक्चर". Focus Projects. Winlab, Rutgers University. Retrieved May 23, 2016.
  26. Ward, Mark (2012-09-14). "यूरोप पुरानी इंटरनेट पता सीमाओं को पार करता है". BBC News (in British English). Retrieved 2017-02-28.
  27. Steve Deering & Bob Hinden, Co-Chairs of the IETF's IP Next Generation Working Group (November 6, 1999). "Statement on IPv6 Address Privacy". Retrieved 2017-02-28.