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)
|
|
---|---|---|---|
Authors | David Meyer , Randy Bush | ||
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) | |
Action Holders |
(None)
|
||
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 toShow full document text