Some Internet Architectural Guidelines and Philosophy
RFC 3439

Document Type RFC - Informational (December 2002; Errata)
Updates RFC 1958
Was draft-ymbk-arch-guidelines (individual in tsv area)
Last updated 2015-10-14
Stream IETF
Formats plain text pdf htmlized with errata bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 3439 (Informational)
Consensus Boilerplate Unknown
Telechat date
Responsible AD Allison Mankin
IESG note Published as RFC 3439 - 2002-Dec-11
Send notices to <dmm@1-4-5.net>
Network Working Group                                            R. Bush
Request for Comments: 3439                                      D. Meyer
Updates: 1958                                              December 2002
Category: Informational

         Some Internet Architectural Guidelines and Philosophy

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 (2002).  All Rights Reserved.

Abstract

   This document extends RFC 1958 by outlining some of the philosophical
   guidelines to which architects and designers of Internet backbone
   networks should adhere.  We describe the Simplicity Principle, which
   states that complexity is the primary mechanism that impedes
   efficient scaling, and discuss its implications on the architecture,
   design and engineering issues found in large scale Internet
   backbones.

Table of Contents

   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . .  2
   2. Large Systems and The Simplicity Principle . . . . . . . . .  3
   2.1. The End-to-End Argument and Simplicity   . . . . . . . . .  3
   2.2. Non-linearity and Network Complexity   . . . . . . . . . .  3
   2.2.1. The Amplification Principle. . . . . . . . . . . . . . .  4
   2.2.2. The Coupling Principle . . . . . . . . . . . . . . . . .  5
   2.3. Complexity lesson from voice. . . . .  . . . . . . . . . .  6
   2.4. Upgrade cost of complexity. . . . . .  . . . . . . . . . .  7
   3. Layering Considered Harmful. . . . . . . . . . . . . . . . .  7
   3.1. Optimization Considered Harmful . . .  . . . . . . . . . .  8
   3.2. Feature Richness Considered Harmful .  . . . . . . . . . .  9
   3.3. Evolution of Transport Efficiency for IP.  . . . . . . . .  9
   3.4. Convergence Layering. . . . . . . . . . .  . . . . . . . .  9
   3.4.1. Note on Transport Protocol Layering. . . . . . . . . . . 11
   3.5. Second Order Effects   . . . . . . . . . . . . . . . . . . 11
   3.6. Instantiating the EOSL Model with IP   . . . . . . . . . . 12
   4. Avoid the Universal Interworking Function. . . . . . . . . . 12
   4.1. Avoid Control Plane Interworking . . . . . . . . . . . . . 13

Bush, et. al.                Informational                      [Page 1]
RFC 3439           Internet Architectural Guidelines       December 2002

   5. Packet versus Circuit Switching: Fundamental Differences . . 13
   5.1. Is PS is inherently more efficient than CS?  . . . . . . . 13
   5.2. Is PS simpler than CS? . . . . . . . . . . . . . . . . . . 14
   5.2.1. Software/Firmware Complexity . . . . . . . . . . . . . . 15
   5.2.2. Macro Operation Complexity . . . . . . . . . . . . . . . 15
   5.2.3. Hardware Complexity. . . . . . . . . . . . . . . . . . . 15
   5.2.4. Power. . . . . . . . . . . . . . . . . . . . . . . . . . 16
   5.2.5. Density. . . . . . . . . . . . . . . . . . . . . . . . . 16
   5.2.6. Fixed versus variable costs. . . . . . . . . . . . . . . 16
   5.2.7. QoS. . . . . . . . . . . . . . . . . . . . . . . . . . . 17
   5.2.8. Flexibility. . . . . . . . . . . . . . . . . . . . . . . 17
   5.3. Relative Complexity  . . . . . . . . . . . . . . . . . . . 17
   5.3.1. HBHI and the OPEX Challenge. . . . . . . . . . . . . . . 18
   6. The Myth of Over-Provisioning. . . . . . . . . . . . . . . . 18
   7. The Myth of Five Nines . . . . . . . . . . . . . . . . . . . 19
   8. Architectural Component Proportionality Law. . . . . . . . . 20
   8.1. Service Delivery Paths . . . . . . . . . . . . . . . . . . 21
   9. Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . 21
   10. Security Considerations . . . . . . . . . . . . . . . . . . 22
   11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 23
   12. References. . . . . . . . . . . . . . . . . . . . . . . . . 23
   13. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . 27
   14. Full Copyright Statement. . . . . . . . . . . . . . . . . . 28

1.  Introduction

   RFC 1958 [RFC1958] describes the underlying principles of the
   Internet architecture.  This note extends that work by outlining some
   of the philosophical guidelines to which architects and designers of
   Internet backbone networks should adhere.  While many of the areas
   outlined in this document may be controversial, the unifying
   principle described here, controlling complexity as a mechanism to
   control costs and reliability, should not be.  Complexity in carrier
   networks can derive from many sources.  However, as stated in
   [DOYLE2002], "Complexity in most systems is driven by the need for
   robustness to uncertainty in their environments and component parts
   far more than by basic functionality".  The major thrust of this
   document, then, is to raise awareness about the complexity of some of
   our current architectures, and to examine the effect such complexity
   will almost certainly have on the IP carrier industry's ability to
Show full document text