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 | 2020-01-21 | ||
| Stream | IETF | ||
| Formats | plain text html 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