The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture
RFC 3724

Document Type RFC - Informational (March 2004; No errata)
Last updated 2013-03-02
Stream IAB
Formats plain text pdf html bibtex
Stream IAB state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
Network Working Group                                      J. Kempf, Ed.
Request for Comments: 3724                               R. Austein, Ed.
Category: Informational                                              IAB
                                                              March 2004

          The Rise of the Middle and the Future of End-to-End:
       Reflections on the Evolution of the Internet Architecture

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.

Abstract

   The end-to-end principle is the core architectural guideline of the
   Internet.  In this document, we briefly examine the development of
   the end-to-end principle as it has been applied to the Internet
   architecture over the years.  We discuss current trends in the
   evolution of the Internet architecture in relation to the end-to-end
   principle, and try to draw some conclusion about the evolution of the
   end-to-end principle, and thus for the Internet architecture which it
   supports, in light of these current trends.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  A Brief History of the End-to-End Principle. . . . . . . . . .  2
   3.  Trends Opposed to the End-to-End Principle . . . . . . . . . .  5
   4.  Whither the End-to-End Principle?. . . . . . . . . . . . . . .  8
   5.  Internet Standards as an Arena for Conflict. . . . . . . . . . 10
   6.  Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . . 11
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
   8.  Security Considerations. . . . . . . . . . . . . . . . . . . . 12
   9.  Informative References . . . . . . . . . . . . . . . . . . . . 12
   10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13
   11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 14

Kempf & Austein              Informational                      [Page 1]
RFC 3724                  Future of End-to-End                March 2004

1.  Introduction

   One of the key architectural guidelines of the Internet is the end-
   to-end principle in the papers by Saltzer, Reed, and Clark [1][2].
   The end-to-end principle was originally articulated as a question of
   where best not to put functions in a communication system.  Yet, in
   the ensuing years, it has evolved to address concerns of maintaining
   openness, increasing reliability and robustness, and preserving the
   properties of user choice and ease of new service development as
   discussed by Blumenthal and Clark in [3]; concerns that were not part
   of the original articulation of the end-to-end principle.

   In this document, we examine how the interpretation of the end-to-end
   principle has evolved over the years, and where it stands currently.
   We examine trends in the development of the Internet that have led to
   pressure to define services in the network, a topic that has already
   received some amount of attention from the IAB in RFC 3238 [5].  We
   describe some considerations about how the end-to-end principle might
   evolve in light of these trends.

2.  A Brief History of the End-to-End Principle

2.1.  In the Beginning...

   The end-to-end principle was originally articulated as a question of
   where best to put functions in a communication system:

      The function in question can completely and correctly be
      implemented only with the knowledge and help of the application
      standing at the end points of the communication system.
      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 communication
      system may be useful as a performance enhancement.) [1].

   A specific example of such a function is delivery guarantees [1].
   The original ARPANET returned a message "Request for Next Message"
   whenever it delivered a packet.  Although this message was found to
   be useful within the network as a form of congestion control, since
   the ARPANET refused to accept another message to the same destination
   until the previous acknowledgment was returned, it was never
   particularly useful as an indication of guaranteed delivery.  The
   problem was that the host stack on the sending host typically doesn't
   want to know just that the network delivered a packet, but rather the
   stack layer on the sending host wants to know that the stack layer on
   the receiving host properly processed the packet.  In terms of modern
   IP stack structure, a reliable transport layer requires an indication
   that transport processing has successfully completed, such as given

Kempf & Austein              Informational                      [Page 2]
Show full document text