RFC3439 日本語訳
3439 Some Internet Architectural Guidelines and Philosophy. R. Bush,D. Meyer. December 2002. (Format: TXT=70333 bytes) (Updates RFC1958) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Bush Request for Comments: 3439 D. Meyer Updates: 1958 December 2002 Category: Informational
コメントを求めるワーキンググループR.ブッシュの要求をネットワークでつないでください: 3439のD.マイヤーアップデート: 1958 2002年12月のカテゴリ: 情報
Some Internet Architectural Guidelines and Philosophy
何らかのインターネットの建築ガイドラインと哲学
Status of this Memo
この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.
Copyright(C)インターネット協会(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.
このドキュメントは、インターネットの基幹ネットワークの建築家とデザイナーが固守するべきである哲学的なガイドラインのいくつかについて概説することによって、RFC1958を広げています。 私たちは、複雑さが効率的なスケーリングを妨害する一次機構であると述べるSimplicity Principleについて説明して、構造で含意について議論します、とデザインと工学問題によって、大規模インターネットの基幹でわかりました。
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . 2 2。 大規模システムと簡単さ原則. . . . . . . . . 3 2.1。 終わりから終わりへの議論と簡単さ. . . . . . . . . 3 2.2。 非線形性とネットワークの複雑さ. . . . . . . . . . 3 2.2.1。 増幅原則。 . . . . . . . . . . . . . . 4 2.2.2. カップリング原則. . . . . . . . . . . . . . . . . 5 2.3。 声からの複雑さ教訓。 . . . . . . . . . . . . . . 6 2.4. 複雑さの費用をアップグレードさせてください。 . . . . . . . . . . . . . . . 7 3. 有害であると考えられて、層にすること。 . . . . . . . . . . . . . . . . 7 3.1. 有害な.83.2であると考えられた最適化。 有害な.93.3であると考えられた豊かを特徴としてください。 IPのための輸送効率の発展。 . . . . . . . . 9 3.4. 集合レイヤリング。 . . . . . . . . . . . . . . . . . . 9 3.4.1. 輸送のときに、レイヤリングについて議定書の中で述べるように注意してください。 . . . . . . . . . . 11 3.5. 2番目に、効果. . . . . . . . . . . . . . . . . . 11 3.6は注文されます。 IP. . . . . . . . . . 12 4のEOSLモデルを例示します。 普遍的な織り込む機能を避けてください。 . . . . . . . . . 12 4.1. コントロール飛行機の織り込. . . . . . . . . . . . . 13むことを避けてください。
Bush, et. al. Informational [Page 1] RFC 3439 Internet Architectural Guidelines December 2002
etブッシュ、アル。 ガイドライン2002年12月に建築している情報[1ページ]のRFC3439インターネット
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
5. パケット対回線交換: 基本的な違い. . 13 5.1。 PSが本来CS?より効率的であるということです。 . . . . . . . 13 5.2. PSはCSより簡単ですか? . . . . . . . . . . . . . . . . . . 14 5.2.1. ソフトウェア/ファームウェアの複雑さ. . . . . . . . . . . . . . 15 5.2.2。 マクロの動作の複雑さ. . . . . . . . . . . . . . . 15 5.2.3。 ハードウェアの複雑さ。 . . . . . . . . . . . . . . . . . . 15 5.2.4. パワー。 . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.2.5. 密度。 . . . . . . . . . . . . . . . . . . . . . . . . 16 5.2.6. 変動費に対して修理されています。 . . . . . . . . . . . . . . 16 5.2.7. QoS。 . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.2.8. 柔軟性。 . . . . . . . . . . . . . . . . . . . . . . 17 5.3. 相対的な複雑さ. . . . . . . . . . . . . . . . . . . 17 5.3.1。 HBHIとOPEXは挑戦します。 . . . . . . . . . . . . . . 18 6. 食糧を供給し過ぎることに関する神話。 . . . . . . . . . . . . . . . 18 7. 5Nines . . . . . . . . . . . . . . . . . . . 19 8に関する神話 建築コンポーネント比例性法。 . . . . . . . . 20 8.1. 配送経路. . . . . . . . . . . . . . . . . . 21 9を修理してください。 結論。 . . . . . . . . . . . . . . . . . . . . . . . . 21 10. セキュリティ問題. . . . . . . . . . . . . . . . . . 22 11。 承認. . . . . . . . . . . . . . . . . . . . . . 23 12。 参照。 . . . . . . . . . . . . . . . . . . . . . . . . 23 13. 作者のアドレス。 . . . . . . . . . . . . . . . . . . . . 27 14. 完全な著作権宣言文。 . . . . . . . . . . . . . . . . . 28
1. Introduction
1. 序論
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 succeed.
RFC1958[RFC1958]はインターネット構造の基本的な原則について説明します。 哲学的なガイドラインのいくつかについてどの建築家に概説するかによって働いてください。そうすれば、インターネットの基幹ネットワークのデザイナーが付着するべきであるというこの音は、広がっています。 本書では概説された領域の多くが論議を呼ぶかもしれない間、コストと信頼性を制御するためにメカニズムとして複雑さを制御して、ここで説明された統一原則があるべきではありません。 キャリヤーネットワークにおける複雑さが多くのソースに由来できます。 しかしながら、[DOYLE2002]に述べられているように、「ほとんどのシステムにおける複雑さは彼らの環境とコンポーネントの部品の不確実性への丈夫さの必要性で基本機能よりはるかにさらにやる気満々です」。 このドキュメントの主要な突きは、次に、私たちの現在の建築のいくつかの複雑さに関して関心を高めて、そのような複雑さが成功するIPキャリヤー産業の性能にほぼ確実に持っている効果を調べることです。
The rest of this document is organized as follows: The first section describes the Simplicity Principle and its implications for the design of very large systems. The remainder of the document outlines the high-level consequences of the Simplicity Principle and how it should guide large scale network architecture and design approaches.
このドキュメントの残りは以下の通り組織化されます: 最初のセクションは非常に大きいシステムの設計のためにSimplicity Principleとその含意について説明します。ドキュメントの残りはSimplicity Principleとそれがどう大規模ネットワーク構造と設計手法を誘導するべきであるかに関するハイレベルの結果について概説します。
Bush, et. al. Informational [Page 2] RFC 3439 Internet Architectural Guidelines December 2002
etブッシュ、アル。 ガイドライン2002年12月に建築している情報[2ページ]のRFC3439インターネット
2. Large Systems and The Simplicity Principle
2. 大規模システムと簡単さ原則
The Simplicity Principle, which was perhaps first articulated by Mike O'Dell, former Chief Architect at UUNET, states that complexity is the primary mechanism which impedes efficient scaling, and as a result is the primary driver of increases in both capital expenditures (CAPEX) and operational expenditures (OPEX). The implication for carrier IP networks then, is that to be successful we must drive our architectures and designs toward the simplest possible solutions.
Simplicity Principle(最初に、恐らくマイク・オデルによって明確に話されました)(UUNETの元Chief Architect)は複雑さが効率的なスケーリングを妨害する一次機構であり、その結果資本支出(CAPEX)と操作上の費用(OPEX)の両方の増加の第一のドライバーであると述べます。 IPがその時ネットワークでつなぐキャリヤーのための含意はうまくいくために、私たちが可能な限り簡単な解決策に向かって構造とデザインを追い立てなければならないということです。
2.1. The End-to-End Argument and Simplicity
2.1. 終わりから終わりへの議論と簡単さ
The end-to-end argument, which is described in [SALTZER] (as well as in RFC 1958 [RFC1958]), contends that "end-to-end protocol design should not rely on the maintenance of state (i.e., information about the state of the end-to-end communication) inside the network. Such state should be maintained only in the end points, in such a way that the state can only be destroyed when the end point itself breaks." This property has also been related to Clark's "fate-sharing" concept [CLARK]. We can see that the end-to-end principle leads directly to the Simplicity Principle by examining the so-called "hourglass" formulation of the Internet architecture [WILLINGER2002]. In this model, the thin waist of the hourglass is envisioned as the (minimalist) IP layer, and any additional complexity is added above the IP layer. In short, the complexity of the Internet belongs at the edges, and the IP layer of the Internet should remain as simple as possible.
「終わりから終わりへのプロトコルデザインはネットワークの中で状態(すなわち、エンド・ツー・エンド通信の状態の情報)の維持に依存するべきではありません。」と、終わりから終わりへの議論([SALTZER](RFC1958[RFC1958]と同じくらいよく)で説明される)は主張します。 「そのような状態は結局だけポイントであることが支持されるべきです、エンドポイント自体が壊れると状態を破壊できるだけであるような方法で。」 また、この特性はクラークの「運命を共有している」概念[クラーク]に関連しました。 私たちは、終わりから終わりへの原則がインターネット構造[WILLINGER2002]のいわゆる「砂時計」定式化を調べることによって直接Simplicity Principleに通じるのを見ることができます。 このモデルでは、砂時計の薄いウエストは(ミニマリスト)IP層として思い描かれます、そして、どんな追加複雑さもIP層を超えて加えられます。 要するに、インターネットの複雑さは縁で属します、そして、インターネットのIP層はできるだけ簡単なままで残っているはずです。
Finally, note that the End-to-End Argument does not imply that the core of the Internet will not contain and maintain state. In fact, a huge amount coarse grained state is maintained in the Internet's core (e.g., routing state). However, the important point here is that this (coarse grained) state is almost orthogonal to the state maintained by the end-points (e.g., hosts). It is this minimization of interaction that contributes to simplicity. As a result, consideration of "core vs. end-point" state interaction is crucial when analyzing protocols such as Network Address Translation (NAT), which reduce the transparency between network and hosts.
最終的に、Endから終わりへのArgumentが、インターネットのコアが状態を含んでいて、維持しないのを含意しないことに注意してください。 事実上、膨大な量下品な粒状の状態はインターネットのコア(例えば、ルーティング状態)で維持されます。 しかしながら、ここの重要なポイントがそれである、これ、(粗さ、粒状、)、状態はエンドポイント(例えば、ホスト)によって維持された状態とほとんど直交しています。 それは簡単さに貢献する相互作用のこの最小化です。 ネットワークとホストの間の透明を減少させるNetwork Address Translation(NAT)などのプロトコルを分析するとき、その結果、「コア対エンドポイント」州の相互作用の考慮は重要です。
2.2. Non-linearity and Network Complexity
2.2. 非線形性とネットワークの複雑さ
Complex architectures and designs have been (and continue to be) among the most significant and challenging barriers to building cost- effective large scale IP networks. Consider, for example, the task of building a large scale packet network. Industry experience has shown that building such a network is a different activity (and hence requires a different skill set) than building a small to medium scale
そして、複雑な構造とデザインがあった、(続けている、)、ビルへの最も重要で挑戦的なバリアの中では、有効な大規模IPネットワークかかってください。 例えば大規模パケット網を築き上げるタスクを考えてください。 産業経験は、そのようなネットワークを造るのが、小さくaを中くらいのスケールまで建てるより異なった活動(そして、したがって、異なったスキルセットを必要とする)であることを示しました。
Bush, et. al. Informational [Page 3] RFC 3439 Internet Architectural Guidelines December 2002
etブッシュ、アル。 ガイドライン2002年12月に建築している情報[3ページ]のRFC3439インターネット
network, and as such doesn't have the same properties. In particular, the largest networks exhibit, both in theory and in practice, architecture, design, and engineering non-linearities which are not exhibited at smaller scale. We call this Architecture, Design, and Engineering (ADE) non-linearity. That is, systems such as the Internet could be described as highly self-dissimilar, with extremely different scales and levels of abstraction [CARLSON]. The ADE non-linearity property is based upon two well-known principles from non-linear systems theory [THOMPSON]:
同じ特性をネットワークでつないで、そういうものとして持っていません。 特に、最も大きいネットワークは理論上と習慣で、よりわずかなスケールで示されない構造、デザイン、および工学非線形性を示します。 私たちはこのArchitecture、Design、およびEngineering(ADE)非線形性を呼びます。 自己非常に異なるとすなわち、インターネットなどのシステムを記述できました、非常に異なったスケールとレベルの抽象化[カールソン]で。 ADE非線形性の特性は非線形のシステム理論[トンプソン]から2つの周知の原則に基づいています:
2.2.1. The Amplification Principle
2.2.1. 増幅原則
The Amplification Principle states that there are non-linearities which occur at large scale which do not occur at small to medium scale.
Amplification Principleは、大規模で起こる非線形性があると述べます(中くらいのスケールに小さいところに起こりません)。
COROLLARY: In many large networks, even small things can and do cause huge events. In system-theoretic terms, in large systems such as these, even small perturbations on the input to a process can destabilize the system's output.
推論: 多くの大きいネットワークでは、小さいものさえ、引き起こして、巨大な出来事を引き起こす場合があります。 システム理論的な用語、これらなどの大規模システムでは、過程への入力での小さい摂動さえシステムの出力を動揺させることができます。
An important example of the Amplification Principle is non-linear resonant amplification, which is a powerful process that can transform dynamic systems, such as large networks, in surprising ways with seemingly small fluctuations. These small fluctuations may slowly accumulate, and if they are synchronized with other cycles, may produce major changes. Resonant phenomena are examples of non- linear behavior where small fluctuations may be amplified and have influences far exceeding their initial sizes. The natural world is filled with examples of resonant behavior that can produce system- wide changes, such as the destruction of the Tacoma Narrows bridge (due to the resonant amplification of small gusts of wind). Other examples include the gaps in the asteroid belts and rings of Saturn which are created by non-linear resonant amplification. Some features of human behavior and most pilgrimage systems are influenced by resonant phenomena involving the dynamics of the solar system, such as solar days, the 27.3 day (sidereal) and 29.5 day (synodic) cycles of the moon or the 365.25 day cycle of the sun.
Amplification Principleの重要な例は非線形の共鳴な増幅です、大きいネットワークなどのように、外観上小さい変動に伴う驚異的な方法で。(増幅はダイナミックなシステムを変えることができる強力な過程です)。 これらの小相場はゆっくり蓄積するかもしれません、そして、それらが他のサイクルに連動するなら、大きな変化を発生させるかもしれません。 共鳴な現象は小相場が遠くに増幅されて、影響を持っているかもしれないそれらの初期のサイズを超えている非直線的な振舞いに関する例です。 自然界はシステムの広い変化を発生させることができる共鳴な振舞いに関する例で満たされます、タコマNarrows橋(風の小さい突風の共鳴な増幅による)の破壊などのように。 他の例は非線形の共鳴な増幅で作成される小惑星帯と土星の環にギャップを含んでいます。 人間挙動のいくつかの特徴とほとんどの巡礼の旅システムが太陽系の力学にかかわる共鳴な現象によって影響を及ぼされます、太陽の日、月の27.3日(星の)と29.5日(synodic)のサイクルまたは太陽の365.25日のサイクルなどのように。
In the Internet domain, it has been shown that increased inter- connectivity results in more complex and often slower BGP routing convergence [AHUJA]. A related result is that a small amount of inter-connectivity causes the output of a routing mesh to be significantly more complex than its input [GRIFFIN]. An important method for reducing amplification is ensure that local changes have only local effect (this is as opposed to systems in which local changes have global effect). Finally, ATM provides an excellent example of an amplification effect: if you lose one cell, you destroy
インターネットドメインでは、増加する相互の接続性が、より複雑でしばしばより遅いBGPルーティング集合[AHUJA]をもたらすのが示されました。 関連する結果は少量の相互接続性が、ルーティングメッシュの出力が入力[グリフィン]よりかなり複雑であることを引き起こすということです。 増幅を抑えるための重要な方法は地域変化には局所効果しかないのを確実にすること(これは地域変化がグローバルな効果を持っているシステムと対照的にある)です。 最終的に、ATMは増幅作用に関する好例を提供します: あなたが1つのセルを失うなら破壊する、あなたは破壊します。
Bush, et. al. Informational [Page 4] RFC 3439 Internet Architectural Guidelines December 2002
etブッシュ、アル。 ガイドライン2002年12月に建築している情報[4ページ]のRFC3439インターネット
the entire packet (and it gets worse, as in the absence of mechanisms such as Early Packet Discard [ROMANOV], you will continue to carry the already damaged packet).
全体のパケット(それはメカニズムがないときEarly Packet Discard[ロマーノフ]などのように、より悪くなって、あなたは、既に破損しているパケットを運び続けるでしょう)。
Another interesting example of amplification comes from the engineering domain, and is described in [CARLSON]. They consider the Boeing 777, which is a "fly-by-wire" aircraft, containing as many as 150,000 subsystems and approximately 1000 CPUs. What they observe is that while the 777 is robust to large-scale atmospheric disturbances, turbulence boundaries, and variations in cargo loads (to name a few), it could be catastrophically disabled my microscopic alterations in a very few large CPUs (as the point out, fortunately this is a very rare occurrence). This example illustrates the issue "that complexity can amplify small perturbations, and the design engineer must ensure such perturbations are extremely rare." [CARLSON]
増幅の別のおもしろい例は、工学ドメインから来て、[カールソン]で説明されます。 最大15万のサブシステムとおよそ1000個のCPUを含んで、彼らはボーイング777を考えます。(それは、「ワイヤによるハエ」航空機です)。 彼らが777が貨物荷重(いくつかを命名する)の大規模な大気擾乱、乱れ境界、および変化に強健である間それが不運に強健であるかもしれないということであることを観測することはaほんのわずかな大きいCPUで私の顕微鏡の変更を無効にしました(ポイントとして、外では、幸い、これは非常にまれな発生です)。 この例は問題を例証します。「複雑さは小さい摂動を増幅できて、設計技師はそのような摂動が確実に非常にまれになるようにしなければなりません」。 [カールソン]
2.2.2. The Coupling Principle
2.2.2. カップリング原則
The Coupling Principle states that as things get larger, they often exhibit increased interdependence between components.
Coupling Principleは、いろいろなことが増大するのに従ってしばしばコンポーネントの間の増加する相互依存を示すと述べます。
COROLLARY: The more events that simultaneously occur, the larger the likelihood that two or more will interact. This phenomenon has also been termed "unforeseen feature interaction" [WILLINGER2002].
推論: そんなに同時の、より多くの出来事が起これば起こるほど、その2以上が相互作用させる見込みは、より大きいです。 また、この現象は「予期しない機能競合」[WILLINGER2002]と呼ばれました。
Much of the non-linearity observed large systems is largely due to coupling. This coupling has both horizontal and vertical components. In the context of networking, horizontal coupling is exhibited between the same protocol layer, while vertical coupling occurs between layers.
非線形性の観測された大規模システムの多くが主にカップリングのためです。 このカップリングには、水平なものと同様に垂直なコンポーネントがあります。 ネットワークの文脈では、水平なカップリングは同じプロトコル層の間に示されますが、垂直なカップリングは層の間に現れます。
Coupling is exhibited by a wide variety of natural systems, including plasma macro-instabilities (hydro-magnetic, e.g., kink, fire-hose, mirror, ballooning, tearing, trapped-particle effects) [NAVE], as well as various kinds of electrochemical systems (consider the custom fluorescent nucleotide synthesis/nucleic acid labeling problem [WARD]). Coupling of clock physical periodicity has also been observed [JACOBSON], as well as coupling of various types of biological cycles.
カップリングはさまざまな自然のシステムによって示されます、プラズママクロ不安定性を含んでいて(水力磁気です、例えば、消火ホース、鏡、膨張が引き裂かれる捕捉粒子効果をねじれさせてください)[NAVE]、様々な種類の電気化学のシステムと同様に(習慣が問題[区]をラベルする蛍光ヌクレオチド合成/核酸であると考えてください)。 物理的な周期性がまた、観測されて[ジェーコブソン]、結合するのをさせる様々なタイプの生体リズムの時計のカップリング。
Several canonical examples also exist in well known network systems. Examples include the synchronization of various control loops, such as routing update synchronization and TCP Slow Start synchronization [FLOYD,JACOBSON]. An important result of these observations is that coupling is intimately related to synchronization. Injecting randomness into these systems is one way to reduce coupling.
また、いくつかの正準な例がよく知られるところに存在しています。ネットワーク・システム例は様々なコントロールループの同期を含んでいます、ルーティングアップデート同期やTCP Slow Start同期[フロイド、ジェーコブソン]のように。 これらの観測の重要な結果はカップリングが親密に同期に関連するということです。 これらのシステムに偶発性を注ぐのはカップリングを減少させることにおいて一方通行です。
Bush, et. al. Informational [Page 5] RFC 3439 Internet Architectural Guidelines December 2002
etブッシュ、アル。 ガイドライン2002年12月に建築している情報[5ページ]のRFC3439インターネット
Interestingly, in analyzing risk factors for the Public Switched Telephone Network (PSTN), Charles Perrow decomposes the complexity problem along two related axes, which he terms "interactions" and "coupling" [PERROW]. Perrow cites interactions and coupling as significant factors in determining the reliability of a complex system (and in particular, the PSTN). In this model, interactions refer to the dependencies between components (linear or non-linear), while coupling refers to the flexibility in a system. Systems with simple, linear interactions have components that affect only other components that are functionally downstream. Complex system components interact with many other components in different and possibly distant parts of the system. Loosely coupled systems are said to have more flexibility in time constraints, sequencing, and environmental assumptions than do tightly coupled systems. In addition, systems with complex interactions and tight coupling are likely to have unforeseen failure states (of course, complex interactions permit more complications to develop and make the system hard to understand and predict); this behavior is also described in [WILLINGER2002]. Tight coupling also means that the system has less flexibility in recovering from failure states.
Public Switched Telephone Network(PSTN)のために危険因子を分析する際に、おもしろく、チャールズ・ペローは2本の関連する軸に沿って複雑さ問題を分解します。彼は「相互作用」と「カップリング」[ペロー]と軸を呼びます。 ペローは相互作用を引用します、そして、重要であるとして結合するのは、複合システム(そして、特にPSTN)の信頼性を決定しながら、計算に入れます。 このモデルで、相互作用はコンポーネント(直線的であるか非線形の)の間の依存について言及します、カップリングがシステムの柔軟性について言及しますが。 簡単で、直線的な相互作用に伴うシステムには、他の機能上川下であるコンポーネントだけに影響するコンポーネントがあります。 複合システムの部品はシステムの異なってことによると遠方の部分の他の多くのコンポーネントと対話します。 弱連結システムは時間規制、配列、および環境仮定における密結合システムをするより多くの柔軟性を持っていると言われています。さらに、複雑な相互作用と密結合があるシステムは予期しない失敗州を持っていそうです(もちろん、複雑な相互作用は、より多くの複雑さが開発して、システムを理解して、予測するのを困難にすることを許可します)。 また、この振舞いは[WILLINGER2002]で説明されます。 また、密結合は、システムが失敗州から回復する際に、より少ない柔軟性を持っていることを意味します。
The PSTN's SS7 control network provides an interesting example of what can go wrong with a tightly coupled complex system. Outages such as the well publicized 1991 outage of AT&T's SS7 demonstrates the phenomenon: the outage was caused by software bugs in the switches' crash recovery code. In this case, one switch crashed due to a hardware glitch. When this switch came back up, it (plus a reasonably probable timing event) caused its neighbors to crash When the neighboring switches came back up, they caused their neighbors to crash, and so on [NEUMANN] (the root cause turned out to be a misplaced 'break' statement; this is an excellent example of cross- layer coupling). This phenomenon is similar to the phase-locking of weakly coupled oscillators, in which random variations in sequence times plays an important role in system stability [THOMPSON].
PSTNのSS7規制ネットワークは何が密結合複合システムで支障をきたすことができるかに関するおもしろい例を提供します。 1991年のAT&TのSS7のよくピーアールされた供給停止などの供給停止は現象を示します: 供給停止はソフトウェアのバグによってスイッチの速成の回復コードで引き起こされました。 この場合、1個のスイッチがハードウェア不調のためクラッシュしました。 このスイッチが来て戻ったとき、それ(合理的にありえそうなタイミング出来事)で、隣人は隣接しているスイッチが来て戻したWhenを墜落させて、それらは墜落させる彼らの隣人など[ノイマン]を引き起こしました(根本的原因は置き違えられた'中断'声明であると判明しました; これは十字層のカップリングに関する好例です)。 この現象は弱々しく結合されていることのフェーズロック振動子と同様です。その不規則変動では、連続して回はシステムの安定性[トンプソン]で重要な役割を果たします。
2.3. Complexity lesson from voice
2.3. 声からの複雑さ教訓
In the 1970s and 1980s, the voice carriers competed by adding features which drove substantial increases in the complexity of the PSTN, especially in the Class 5 switching infrastructure. This complexity was typically software-based, not hardware driven, and therefore had cost curves worse than Moore's Law. In summary, poor margins on voice products today are due to OPEX and CAPEX costs not dropping as we might expect from simple hardware-bound implementations.
1970年代と1980年代に、音声キャリヤーはPSTNの複雑さのかなりの増加を追い立てた特徴を加えることによって、競争しました、特にClass5切り換えインフラストラクチャで。 この複雑さが通常ソフトウェアベースであり、どんなハードウェアでも、費用曲線は、ムーアの法則より悪く追い立てて、したがって、なりませんでした。 概要には、今日、声の生成物の貧しいマージンが私たちが簡単なハードウェア行きの実現から予想するかもしれないように低下しないOPEXとCAPEXコストのためにあります。
Bush, et. al. Informational [Page 6] RFC 3439 Internet Architectural Guidelines December 2002
etブッシュ、アル。 ガイドライン2002年12月に建築している情報[6ページ]のRFC3439インターネット
2.4. Upgrade cost of complexity
2.4. 複雑さのアップグレード費用
Consider the cost of providing new features in a complex network. The traditional voice network has little intelligence in its edge devices (phone instruments), and a very smart core. The Internet has smart edges, computers with operating systems, applications, etc., and a simple core, which consists of a control plane and packet forwarding engines. Adding an new Internet service is just a matter of distributing an application to the a few consenting desktops who wish to use it. Compare this to adding a service to voice, where one has to upgrade the entire core.
複雑なネットワークに新機能を提供する費用を考えてください。 伝統的な声のネットワークはエッジデバイス(電話器具)、および非常に賢いコアにほとんど知性を持っていません。 インターネットには、賢い縁、オペレーティングシステムがあるコンピュータ、アプリケーション、など、および簡単なコアがあります。(それは、制御飛行機とパケット推進エンジンから成ります)。 新しいインターネットのサービスが正当であると言い足す、アプリケーションを配布するのがaが重要であるそれを使用することを願っているいくつかの同意デスクトップ。 サービスを声に追加するとこれを比較してください。(そこでは、1つが全体のコアをアップグレードさせなければなりません)。
3. Layering Considered Harmful
3. 有害であると考えられて、層にします。
There are several generic properties of layering, or vertical integration as applied to networking. In general, a layer as defined in our context implements one or more of
レイヤリングの数個の一般的な特性、またはネットワークへの適用されるとしての垂直統合があります。 一般に、aは私たちの文脈が1つか以上を実行する定義されたコネとして層にされます。
Error Control: The layer makes the "channel" more reliable
(e.g., reliable transport layer)
誤り制御: 層で、「チャンネル」は、より信頼できるようになります。(例えば、信頼できるトランスポート層)
Flow Control: The layer avoids flooding slower peer (e.g.,
ATM flow control)
フロー制御: 層は、より遅い同輩をあふれさせるのを避けます。(例えば、ATMフロー制御)
Fragmentation: Dividing large data chunks into smaller
pieces, and subsequent reassembly (e.g., TCP
MSS fragmentation/reassembly)
断片化: 大きいデータ塊をより小さい断片、およびその後の再アセンブリに分割します。(例えば、TCP MSS断片化/再アセンブリ)
Multiplexing: Allow several higher level sessions share
single lower level "connection" (e.g., ATM PVC)
マルチプレクシング: シェア単一の下側の平らな「接続」をいくつかの、より高い平らなセッションに許容してください。(例えば、気圧PVC)
Connection Setup: Handshaking with peer (e.g., TCP three-way
handshake, ATM ILMI)
接続設定: 同輩がいるハンドシェイク(例えば、TCP3方向ハンドシェイク、ATM ILMI)
Addressing/Naming: Locating, managing identifiers associated
with entities (e.g., GOSSIP 2 NSAP Structure
[RFC1629])
アドレシング/命名: 実体に関連している場所を見つけていて、管理している識別子(例えば、ゴシップ2NSAP構造[RFC1629])
Layering of this type does have various conceptual and structuring advantages. However, in the data networking context structured layering implies that the functions of each layer are carried out completely before the protocol data unit is passed to the next layer. This means that the optimization of each layer has to be done separately. Such ordering constraints are in conflict with efficient implementation of data manipulation functions. One could accuse the layered model (e.g., TCP/IP and ISO OSI) of causing this conflict. In fact, the operations of multiplexing and segmentation both hide vital information that lower layers may need to optimize their
このタイプのレイヤリングには、概念的、そして、構造の様々な利点があります。 しかしながら、データネットワーク文脈では、構造化されたレイヤリングは、プロトコルデータ単位が次の層に通過される完全に前にそれぞれの層の関数が行われるのを含意します。 これは、それぞれの層の最適化が別々に完了していなければならないことを意味します。 そのような注文規制はデータマニピュレーション機能の効率的な実現との闘争中です。 人は、この闘争を引き起こすので、層にされたモデル(例えば、TCP/IPとISO OSI)を起訴できました。 事実上、マルチプレクシングと分割の操作がともに、下層が、最適化する必要があるかもしれないという極めて重要な情報を隠す、それら
Bush, et. al. Informational [Page 7] RFC 3439 Internet Architectural Guidelines December 2002
etブッシュ、アル。 ガイドライン2002年12月に建築している情報[7ページ]のRFC3439インターネット
performance. For example, layer N may duplicate lower level functionality, e.g., error recovery hop-hop versus end-to-end error recovery. In addition, different layers may need the same information (e.g., time stamp): layer N may need layer N-2 information (e.g., lower layer packet sizes), and the like [WAKEMAN]. A related and even more ironic statement comes from Tennenhouse's classic paper, "Layered Multiplexing Considered Harmful" [TENNENHOUSE]: "The ATM approach to broadband networking is presently being pursued within the CCITT (and elsewhere) as the unifying mechanism for the support of service integration, rate adaptation, and jitter control within the lower layers of the network architecture. This position paper is specifically concerned with the jitter arising from the design of the "middle" and "upper" layers that operate within the end systems and relays of multi-service networks (MSNs)."
性能。 例えば、層Nは終わりから終わりへのエラー回復に対して下のレベルの機能性、例えばエラー回復ホップホップをコピーするかもしれません。 さらに、異なった層は同じ情報(例えば、タイムスタンプ)を必要とするかもしれません: 層Nは層のN-2情報(例えば、下層パケットサイズ)、および同様のもの[ウェイクマン]を必要とするかもしれません。 関連してさらに皮肉な声明はTennenhouseの古典的な紙、「有害であると考えられた層にされたマルチプレクシング」[TENNENHOUSE]から来ます: 「広帯域のネットワークへのATMアプローチは現在、サービス統合、レート適合、およびジターコントロールのサポートのための統一メカニズムとしてネットワークアーキテクチャの下層の中でCCITT(ほかの場所)の中で追求されています。」 「この方針書は明確にマルチサービスネットワークのエンドシステムとリレーの中に作動する「中央」の、そして、「上側」の層のデザインから起こるジターに関係があります(MSNs)。」
As a result of inter-layer dependencies, increased layering can quickly lead to violation of the Simplicity Principle. Industry experience has taught us that increased layering frequently increases complexity and hence leads to increases in OPEX, as is predicted by the Simplicity Principle. A corollary is stated in RFC 1925 [RFC1925], section 2(5):
相互層の依存の結果、増加するレイヤリングは急速にSimplicity Principleの違反につながることができます。 産業経験は、増加するレイヤリングが複雑さを頻繁に増加させて、したがって、OPEXの増加につながることを私たちに教えました、Simplicity Principleによって予測されるように。 推論はRFC1925[RFC1925]、セクション2(5)で述べられています:
"It is always possible to agglutinate multiple separate problems
into a single complex interdependent solution. In most cases
this is a bad idea."
「ただ一つの複雑な互いに依存している解決策に複数の別々の問題を膠着させるのはいつも可能です。」 「多くの場合、これは悪い考えです。」
The first order conclusion then, is that horizontal (as opposed to vertical) separation may be more cost-effective and reliable in the long term.
そして最初のオーダー結論は水平な(垂直と対照的に)分離が長期でより費用対効果に優れていて信頼できるかもしれないということです。
3.1. Optimization Considered Harmful
3.1. 有害であると考えられた最適化
A corollary of the layering arguments above is that optimization can also be considered harmful. In particular, optimization introduces complexity, and as well as introducing tighter coupling between components and layers.
上のレイヤリング議論の推論はまた、有害であると最適化を考えることができるということです。 最適化は、特に、複雑さを導入して、コンポーネントと層によりきついカップリングを取り入れることと同様にそうします。
An important and related effect of optimization is described by the Law of Diminishing Returns, which states that if one factor of production is increased while the others remain constant, the overall returns will relatively decrease after a certain point [SPILLMAN]. The implication here is that trying to squeeze out efficiency past that point only adds complexity, and hence leads to less reliable systems.
最適化の重要で関連する効果がDiminishing Returnsの法によって説明される、比較的、ある一定のポイント[スピルマン]の後に減少してください。Diminishing Returnsは他のものが一定のままでいますが、1つの生産要素が増加しているなら、総合的なリターンがなる増加と述べます。 ポイントが複雑さを追加するだけであり、したがって、それほど高信頼でないシステムにつながるという含意には、効率を過ぎて絞り出そうとするそれがここにいます。
Bush, et. al. Informational [Page 8] RFC 3439 Internet Architectural Guidelines December 2002
etブッシュ、アル。 ガイドライン2002年12月に建築している情報[8ページ]のRFC3439インターネット
3.2. Feature Richness Considered Harmful
3.2. 有害であると考えられた特徴豊か
While adding any new feature may be considered a gain (and in fact frequently differentiates vendors of various types of equipment), but there is a danger. The danger is in increased system complexity.
どんな新機能も加えている間、利得であると考えられるかもしれませんが(そして、事実上、頻繁に様々なタイプの設備の業者を微分します)、危険があります。 増加するシステムの複雑さに危険があります。
3.3. Evolution of Transport Efficiency for IP
3.3. IPのための輸送効率の発展
The evolution of transport infrastructures for IP offers a good example of how decreasing vertical integration has lead to various efficiencies. In particular,
IPのための輸送インフラの発展は減少している垂直統合にはリードがどう様々な効率まであるかに関する好例を提供します。 特に
| IP over ATM over SONET -->
| IP over SONET over WDM -->
| IP over WDM
|
\|/
Decreasing complexity, CAPEX, OPEX
| Sonetの上の気圧でのIP-->。| WDMの上のSonetの上のIP-->。| WDMの上のIP| \|/減少している複雑さ、CAPEX、OPEX
The key point here is that layers are removed resulting in CAPEX and OPEX efficiencies.
ここの要所はCAPEXとOPEX効率をもたらしながら層を取り除くということです。
3.4. Convergence Layering
3.4. 集合レイヤリング
Convergence is related to the layering concepts described above in that convergence is achieved via a "convergence layer". The end state of the convergence argument is the concept of Everything Over Some Layer (EOSL). Conduit, DWDM, fiber, ATM, MPLS, and even IP have all been proposed as convergence layers. It is important to note that since layering typically drives OPEX up, we expect convergence will as well. This observation is again consistent with industry experience.
集合は集合が「集合層」を通して達成されるので上で説明されたレイヤリング概念に関連します。 集合議論の端の状態はEverything Over Some Layer(EOSL)の概念です。 集合が層にされるとき、導管、DWDM、ファイバー、ATM、MPLS、およびIP皆、さえ提案されました。 レイヤリングが上がるまでOPEXを通常運転して、私たちが、また、集合がそうすると予想することに注意するのは重要です。 この観測は再び、産業経験と一致しています。
There are many notable examples of convergence layer failure. Perhaps the most germane example is IP over ATM. The immediate and most obvious consequence of ATM layering is the so-called cell tax: First, note that the complete answer on ATM efficiency is that it depends upon packet size distributions. Let's assume that typical Internet type traffic patterns, which tend to have high percentages of packets at 40, 44, and 552 bytes. Recent data [CAIDA] shows that about 95% of WAN bytes and 85% of packets are TCP. Much of this traffic is composed of 40/44 byte packets.
集合層の故障に関する多くの注目に値する例があります。 恐らく最も適切な例はATMの上のIPです。 ATMレイヤリングの即座の、そして、最も明白な結果はいわゆるセル税です: まず最初に、ATM効率における完全な答えがパケットサイズ配によるということであることに注意してください。 その典型的なインターネットがタイプトラフィック・パターンであると仮定しましょう。(トラフィック・パターンは40、44、および552バイトでパケットの高率を持っている傾向があります)。 最近のデータ[CAIDA]は、およそ95%のWANバイトと85%のパケットがTCPであることを示します。 この交通の大部分は40/44バイトのパケットで構成されます。
Now, consider the case of a a DS3 backbone with PLCP turned on. Then the maximum cell rate is 96,000 cells/sec. If you multiply this value by the number of bits in the payload, you get: 96000 cells/sec * 48 bytes/cell * 8 = 36.864 Mbps. This, however, is unrealistic since it
今度は、PLCPがある背骨がつけたDS3に関するケースを考えてください。 そして、最大のセルレートは9万6000セル/秒です。 ペイロードのビットの数にこの値を掛けるなら、あなたは以下を得ます。 96000セル/秒*の48のバイト/セルの*8 = 36.864Mbps。 しかしながら、それ以来これは非現実的です。
Bush, et. al. Informational [Page 9] RFC 3439 Internet Architectural Guidelines December 2002
etブッシュ、アル。 ガイドライン2002年12月に建築している情報[9ページ]のRFC3439インターネット
assumes perfect payload packing. There are two other things that contribute to the ATM overhead (cell tax): The wasted padding and the 8 byte SNAP header.
完全なペイロードパッキングであると仮定します。 ATMオーバーヘッド(セル税)に貢献する他の2つのものがあります: 無駄な詰め物と8バイトのSNAPヘッダー。
It is the SNAP header which causes most of the problems (and you can't do anything about this), forcing most small packets to consume two cells, with the second cell to be mostly empty padding (this interacts really poorly with the data quoted above, e.g., that most packets are 40-44 byte TCP Ack packets). This causes a loss of about another 16% from the 36.8 Mbps ideal throughput.
It is the SNAP header which causes most of the problems (and you can't do anything about this), forcing most small packets to consume two cells, with the second cell to be mostly empty padding (this interacts really poorly with the data quoted above, e.g., that most packets are 40-44 byte TCP Ack packets). This causes a loss of about another 16% from the 36.8 Mbps ideal throughput.
So the total throughput ends up being (for a DS3):
So the total throughput ends up being (for a DS3):
DS3 Line Rate: 44.736
PLCP Overhead - 4.032
Per Cell Header: - 3.840
SNAP Header & Padding: - 5.900
=========
30.960 Mbps
DS3 Line Rate: 44.736 PLCP Overhead - 4.032 Per Cell Header: - 3.840 SNAP Header & Padding: - 5.900 ========= 30.960 Mbps
Result: With a DS3 line rate of 44.736 Mbps, the total overhead is about 31%.
Result: With a DS3 line rate of 44.736 Mbps, the total overhead is about 31%.
Another way to look at this is that since a large fraction of WAN traffic is comprised of TCP ACKs, one can make a different but related calculation. IP over ATM requires:
Another way to look at this is that since a large fraction of WAN traffic is comprised of TCP ACKs, one can make a different but related calculation. IP over ATM requires:
IP data (40 bytes in this case)
8 bytes SNAP
8 bytes AAL5 stuff
5 bytes for each cell
+ as much more as it takes to fill out the last cell
IP data (40 bytes in this case) 8 bytes SNAP 8 bytes AAL5 stuff 5 bytes for each cell + as much more as it takes to fill out the last cell
On ATM, this becomes two cells - 106 bytes to convey 40 bytes of information. The next most common size seems to be one of several sizes in the 504-556 byte range - 636 bytes to carry IP, TCP, and a 512 byte TCP payload - with messages larger than 1000 bytes running third.
On ATM, this becomes two cells - 106 bytes to convey 40 bytes of information. The next most common size seems to be one of several sizes in the 504-556 byte range - 636 bytes to carry IP, TCP, and a 512 byte TCP payload - with messages larger than 1000 bytes running third.
One would imagine that 87% payload (556 byte message size) is better than 37% payload (TCP Ack size), but it's not the 95-98% that customers are used to, and the predominance of TCP Acks skews the average.
One would imagine that 87% payload (556 byte message size) is better than 37% payload (TCP Ack size), but it's not the 95-98% that customers are used to, and the predominance of TCP Acks skews the average.
Bush, et. al. Informational [Page 10] RFC 3439 Internet Architectural Guidelines December 2002
Bush, et. al. Informational [Page 10] RFC 3439 Internet Architectural Guidelines December 2002
3.4.1. Note on Transport Protocol Layering
3.4.1. Note on Transport Protocol Layering
Protocol layering models are frequently cast as "X over Y" models. In these cases, protocol Y carries protocol X's protocol data units (and possibly control data) over Y's data plane, i.e., Y is a "convergence layer". Examples include Frame Relay over ATM, IP over ATM, and IP over MPLS. While X over Y layering has met with only marginal success [TENNENHOUSE,WAKEMAN], there have been a few notable instances where efficiency can be and is gained. In particular, "X over Y efficiencies" can be realized when there is a kind of "isomorphism" between the X and Y (i.e., there is a small convergence layer). In these cases X's data, and possibly control traffic, are "encapsulated" and transported over Y. Examples include Frame Relay over ATM, and Frame Relay, AAL5 ATM and Ethernet over L2TPv3 [L2TPV3]; the simplifying factors here are that there is no requirement that a shared clock be recovered by the communicating end points, and that control-plane interworking is minimized. An alternative is to interwork the X and Y's control and data planes; control-plane interworking is discussed below.
Protocol layering models are frequently cast as "X over Y" models. In these cases, protocol Y carries protocol X's protocol data units (and possibly control data) over Y's data plane, i.e., Y is a "convergence layer". Examples include Frame Relay over ATM, IP over ATM, and IP over MPLS. While X over Y layering has met with only marginal success [TENNENHOUSE,WAKEMAN], there have been a few notable instances where efficiency can be and is gained. In particular, "X over Y efficiencies" can be realized when there is a kind of "isomorphism" between the X and Y (i.e., there is a small convergence layer). In these cases X's data, and possibly control traffic, are "encapsulated" and transported over Y. Examples include Frame Relay over ATM, and Frame Relay, AAL5 ATM and Ethernet over L2TPv3 [L2TPV3]; the simplifying factors here are that there is no requirement that a shared clock be recovered by the communicating end points, and that control-plane interworking is minimized. An alternative is to interwork the X and Y's control and data planes; control-plane interworking is discussed below.
3.5. Second Order Effects
3.5. Second Order Effects
IP over ATM provides an excellent example of unanticipated second order effects. In particular, Romanov and Floyd's classic study on TCP good-put [ROMANOV] on ATM showed that large UBR buffers (larger than one TCP window size) are required to achieve reasonable performance, that packet discard mechanisms (such as Early Packet Discard, or EPD) improve the effective usage of the bandwidth and that more elaborate service and drop strategies than FIFO+EPD, such as per VC queuing and accounting, might be required at the bottleneck to ensure both high efficiency and fairness. Though all studies clearly indicate that a buffer size not less than one TCP window size is required, the amount of extra buffer required naturally depends on the packet discard mechanism used and is still an open issue.
IP over ATM provides an excellent example of unanticipated second order effects. In particular, Romanov and Floyd's classic study on TCP good-put [ROMANOV] on ATM showed that large UBR buffers (larger than one TCP window size) are required to achieve reasonable performance, that packet discard mechanisms (such as Early Packet Discard, or EPD) improve the effective usage of the bandwidth and that more elaborate service and drop strategies than FIFO+EPD, such as per VC queuing and accounting, might be required at the bottleneck to ensure both high efficiency and fairness. Though all studies clearly indicate that a buffer size not less than one TCP window size is required, the amount of extra buffer required naturally depends on the packet discard mechanism used and is still an open issue.
Examples of this kind of problem with layering abound in practical networking. Consider, for example, the effect of IP transport's implicit assumptions of lower layers. In particular:
Examples of this kind of problem with layering abound in practical networking. Consider, for example, the effect of IP transport's implicit assumptions of lower layers. In particular:
o Packet loss: TCP assumes that packet losses are indications of
congestion, but sometimes losses are from corruption on a wireless
link [RFC3115].
o Packet loss: TCP assumes that packet losses are indications of congestion, but sometimes losses are from corruption on a wireless link [RFC3115].
o Reordered packets: TCP assumes that significantly reordered
packets are indications of congestion. This is not always the
case [FLOYD2001].
o Reordered packets: TCP assumes that significantly reordered packets are indications of congestion. This is not always the case [FLOYD2001].
Bush, et. al. Informational [Page 11] RFC 3439 Internet Architectural Guidelines December 2002
Bush, et. al. Informational [Page 11] RFC 3439 Internet Architectural Guidelines December 2002
o Round-trip times: TCP measures round-trip times, and assumes that
the lack of an acknowledgment within a period of time based on the
measured round-trip time is a packet loss, and therefore an
indication of congestion [KARN].
o Round-trip times: TCP measures round-trip times, and assumes that the lack of an acknowledgment within a period of time based on the measured round-trip time is a packet loss, and therefore an indication of congestion [KARN].
o Congestion control: TCP congestion control implicitly assumes that
all the packets in a flow are treated the same by the network, but
this is not always the case [HANDLEY].
o Congestion control: TCP congestion control implicitly assumes that all the packets in a flow are treated the same by the network, but this is not always the case [HANDLEY].
3.6. Instantiating the EOSL Model with IP
3.6. Instantiating the EOSL Model with IP
While IP is being proposed as a transport for almost everything, the base assumption, that Everything over IP (EOIP) will result in OPEX and CAPEX efficiencies, requires critical examination. In particular, while it is the case that many protocols can be efficiently transported over an IP network (specifically, those protocols that do not need to recover synchronization between the communication end points, such as Frame Relay, Ethernet, and AAL5 ATM), the Simplicity and Layering Principles suggest that EOIP may not represent the most efficient convergence strategy for arbitrary services. Rather, a more CAPEX and OPEX efficient convergence layer might be much lower (again, this behavior is predicted by the Simplicity Principle).
While IP is being proposed as a transport for almost everything, the base assumption, that Everything over IP (EOIP) will result in OPEX and CAPEX efficiencies, requires critical examination. In particular, while it is the case that many protocols can be efficiently transported over an IP network (specifically, those protocols that do not need to recover synchronization between the communication end points, such as Frame Relay, Ethernet, and AAL5 ATM), the Simplicity and Layering Principles suggest that EOIP may not represent the most efficient convergence strategy for arbitrary services. Rather, a more CAPEX and OPEX efficient convergence layer might be much lower (again, this behavior is predicted by the Simplicity Principle).
An example of where EOIP would not be the most OPEX and CAPEX efficient transport would be in those cases where a service or protocol needed SONET-like restoration times (e.g., 50ms). It is not hard to imagine that it would cost more to build and operate an IP network with this kind of restoration and convergence property (if that were even possible) than it would to build the SONET network in the first place.
An example of where EOIP would not be the most OPEX and CAPEX efficient transport would be in those cases where a service or protocol needed SONET-like restoration times (e.g., 50ms). It is not hard to imagine that it would cost more to build and operate an IP network with this kind of restoration and convergence property (if that were even possible) than it would to build the SONET network in the first place.
4. Avoid the Universal Interworking Function
4. Avoid the Universal Interworking Function
While there have been many implementations of Universal Interworking unction (UIWF), IWF approaches have been problematic at large scale. his concern is codified in the Principle of Minimum Intervention BRYANT]:
While there have been many implementations of Universal Interworking unction (UIWF), IWF approaches have been problematic at large scale. his concern is codified in the Principle of Minimum Intervention BRYANT]:
"To minimise the scope of information, and to improve the efficiency of data flow through the Encapsulation Layer, the payload should, where possible, be transported as received without modification."
"To minimise the scope of information, and to improve the efficiency of data flow through the Encapsulation Layer, the payload should, where possible, be transported as received without modification."
Bush, et. al. Informational [Page 12] RFC 3439 Internet Architectural Guidelines December 2002
Bush, et. al. Informational [Page 12] RFC 3439 Internet Architectural Guidelines December 2002
4.1. Avoid Control Plane Interworking
4.1. Avoid Control Plane Interworking
This corollary is best understood in the context of the integrated solutions space. In this case, the architecture and design frequently achieves the worst of all possible worlds. This is due to the fact that such integrated solutions perform poorly at both ends of the performance/CAPEX/OPEX spectrum: the protocols with the least switching demand may have to bear the cost of the most expensive, while the protocols with the most stringent requirements often must make concessions to those with different requirements. Add to this the various control plane interworking issues and you have a large opportunity for failure. In summary, interworking functions should be restricted to data plane interworking and encapsulations, and these functions should be carried out at the edge of the network.
This corollary is best understood in the context of the integrated solutions space. In this case, the architecture and design frequently achieves the worst of all possible worlds. This is due to the fact that such integrated solutions perform poorly at both ends of the performance/CAPEX/OPEX spectrum: the protocols with the least switching demand may have to bear the cost of the most expensive, while the protocols with the most stringent requirements often must make concessions to those with different requirements. Add to this the various control plane interworking issues and you have a large opportunity for failure. In summary, interworking functions should be restricted to data plane interworking and encapsulations, and these functions should be carried out at the edge of the network.
As described above, interworking models have been successful in those cases where there is a kind of "isomorphism" between the layers being interworked. The trade-off here, frequently described as the "Integrated vs. Ships In the Night trade-off" has been examined at various times and at various protocol layers. In general, there are few cases in which such integrated solutions have proven efficient. Multi-protocol BGP [RFC2283] is a subtly different but notable exception. In this case, the control plane is independent of the format of the control data. That is, no control plane data conversion is required, in contrast with control plane interworking models such as the ATM/IP interworking envisioned by some soft-switch manufacturers, and the so-called "PNNI-MPLS SIN" interworking [ATMMPLS].
As described above, interworking models have been successful in those cases where there is a kind of "isomorphism" between the layers being interworked. The trade-off here, frequently described as the "Integrated vs. Ships In the Night trade-off" has been examined at various times and at various protocol layers. In general, there are few cases in which such integrated solutions have proven efficient. Multi-protocol BGP [RFC2283] is a subtly different but notable exception. In this case, the control plane is independent of the format of the control data. That is, no control plane data conversion is required, in contrast with control plane interworking models such as the ATM/IP interworking envisioned by some soft-switch manufacturers, and the so-called "PNNI-MPLS SIN" interworking [ATMMPLS].
5. Packet versus Circuit Switching: Fundamental Differences
5. Packet versus Circuit Switching: Fundamental Differences
Conventional wisdom holds that packet switching (PS) is inherently more efficient than circuit switching (CS), primarily because of the efficiencies that can be gained by statistical multiplexing and the fact that routing and forwarding decisions are made independently in a hop-by-hop fashion [[MOLINERO2002]. Further, it is widely assumed that IP is simpler that circuit switching, and hence should be more economical to deploy and manage [MCK2002]. However, if one examines these and related assumptions, a different picture emerges (see for example [ODLYZKO98]). The following sections discuss these assumptions.
Conventional wisdom holds that packet switching (PS) is inherently more efficient than circuit switching (CS), primarily because of the efficiencies that can be gained by statistical multiplexing and the fact that routing and forwarding decisions are made independently in a hop-by-hop fashion [[MOLINERO2002]. Further, it is widely assumed that IP is simpler that circuit switching, and hence should be more economical to deploy and manage [MCK2002]. However, if one examines these and related assumptions, a different picture emerges (see for example [ODLYZKO98]). The following sections discuss these assumptions.
5.1. Is PS is inherently more efficient than CS?
5.1. Is PS is inherently more efficient than CS?
It is well known that packet switches make efficient use of scarce bandwidth [BARAN]. This efficiency is based on the statistical multiplexing inherent in packet switching. However, we continue to be puzzled by what is generally believed to be the low utilization of
It is well known that packet switches make efficient use of scarce bandwidth [BARAN]. This efficiency is based on the statistical multiplexing inherent in packet switching. However, we continue to be puzzled by what is generally believed to be the low utilization of
Bush, et. al. Informational [Page 13] RFC 3439 Internet Architectural Guidelines December 2002
Bush, et. al. Informational [Page 13] RFC 3439 Internet Architectural Guidelines December 2002
Internet backbones. The first question we might ask is what is the current average utilization of Internet backbones, and how does that relate to the utilization of long distance voice networks? Odlyzko and Coffman [ODLYZKO,COFFMAN] report that the average utilization of links in the IP networks was in the range between 3% and 20% (corporate intranets run in the 3% range, while commercial Internet backbones run in the 15-20% range). On the other hand, the average utilization of long haul voice lines is about 33%. In addition, for 2002, the average utilization of optical networks (all services) appears to be hovering at about 11%, while the historical average is approximately 15% [ML2002]. The question then becomes why we see such utilization levels, especially in light of the assumption that PS is inherently more efficient than CS. The reasons cited by Odlyzko and Coffman include:
Internet backbones. The first question we might ask is what is the current average utilization of Internet backbones, and how does that relate to the utilization of long distance voice networks? Odlyzko and Coffman [ODLYZKO,COFFMAN] report that the average utilization of links in the IP networks was in the range between 3% and 20% (corporate intranets run in the 3% range, while commercial Internet backbones run in the 15-20% range). On the other hand, the average utilization of long haul voice lines is about 33%. In addition, for 2002, the average utilization of optical networks (all services) appears to be hovering at about 11%, while the historical average is approximately 15% [ML2002]. The question then becomes why we see such utilization levels, especially in light of the assumption that PS is inherently more efficient than CS. The reasons cited by Odlyzko and Coffman include:
(i). Internet traffic is extremely asymmetric and bursty, but
links are symmetric and of fixed capacity (i.e., don't know
the traffic matrix, or required link capacities);
(i). Internet traffic is extremely asymmetric and bursty, but links are symmetric and of fixed capacity (i.e., don't know the traffic matrix, or required link capacities);
(ii). It is difficult to predict traffic growth on a link, so
operators tend to add bandwidth aggressively;
(ii). It is difficult to predict traffic growth on a link, so operators tend to add bandwidth aggressively;
(iii). Falling prices for coarser bandwidth granularity make it
appear more economical to add capacity in large increments.
(iii). Falling prices for coarser bandwidth granularity make it appear more economical to add capacity in large increments.
Other static factors include protocol overhead, other kinds of equipment granularity, restoration capacity, and provisioning lag time all contribute to the need to "over-provision" [MC2001].
Other static factors include protocol overhead, other kinds of equipment granularity, restoration capacity, and provisioning lag time all contribute to the need to "over-provision" [MC2001].
5.2. Is PS simpler than CS?
5.2. Is PS simpler than CS?
The end-to-end principle can be interpreted as stating that the complexity of the Internet belongs at the edges. However, today's Internet backbone routers are extremely complex. Further, this complexity scales with line rate. Since the relative complexity of circuit and packet switching seems to have resisted direct analysis, we instead examine several artifacts of packet and circuit switching as complexity metrics. Among the metrics we might look at are software complexity, macro operation complexity, hardware complexity, power consumption, and density. Each of these metrics is considered below.
The end-to-end principle can be interpreted as stating that the complexity of the Internet belongs at the edges. However, today's Internet backbone routers are extremely complex. Further, this complexity scales with line rate. Since the relative complexity of circuit and packet switching seems to have resisted direct analysis, we instead examine several artifacts of packet and circuit switching as complexity metrics. Among the metrics we might look at are software complexity, macro operation complexity, hardware complexity, power consumption, and density. Each of these metrics is considered below.
Bush, et. al. Informational [Page 14] RFC 3439 Internet Architectural Guidelines December 2002
Bush, et. al. Informational [Page 14] RFC 3439 Internet Architectural Guidelines December 2002
5.2.1. Software/Firmware Complexity
5.2.1. Software/Firmware Complexity
One measure of software/firmware complexity is the number of instructions required to program the device. The typical software image for an Internet router requires between eight and ten million instructions (including firmware), whereas a typical transport switch requires on average about three million instructions [MCK2002].
One measure of software/firmware complexity is the number of instructions required to program the device. The typical software image for an Internet router requires between eight and ten million instructions (including firmware), whereas a typical transport switch requires on average about three million instructions [MCK2002].
This difference in software complexity has tended to make Internet routers unreliable, and has notable other second order effects (e.g., it may take a long time to reboot such a router). As another point of comparison, consider that the AT&T (Lucent) 5ESS class 5 switch, which has a huge number of calling features, requires only about twice the number of lines of code as an Internet core router [EICK].
This difference in software complexity has tended to make Internet routers unreliable, and has notable other second order effects (e.g., it may take a long time to reboot such a router). As another point of comparison, consider that the AT&T (Lucent) 5ESS class 5 switch, which has a huge number of calling features, requires only about twice the number of lines of code as an Internet core router [EICK].
Finally, since routers are as much or more software than hardware devices, another result of the code complexity is that the cost of routers benefits less from Moore's Law than less software-intensive devices. This causes a bandwidth/device trade-off that favors bandwidth more than less software-intensive devices.
Finally, since routers are as much or more software than hardware devices, another result of the code complexity is that the cost of routers benefits less from Moore's Law than less software-intensive devices. This causes a bandwidth/device trade-off that favors bandwidth more than less software-intensive devices.
5.2.2. Macro Operation Complexity
5.2.2. Macro Operation Complexity
An Internet router's line card must perform many complex operations, including processing the packet header, longest prefix match, generating ICMP error messages, processing IP header options, and buffering the packet so that TCP congestion control will be effective (this typically requires a buffer of size proportional to the line rate times the RTT, so a buffer will hold around 250 ms of packet data). This doesn't include route and packet filtering, or any QoS or VPN filtering.
An Internet router's line card must perform many complex operations, including processing the packet header, longest prefix match, generating ICMP error messages, processing IP header options, and buffering the packet so that TCP congestion control will be effective (this typically requires a buffer of size proportional to the line rate times the RTT, so a buffer will hold around 250 ms of packet data). This doesn't include route and packet filtering, or any QoS or VPN filtering.
On the other hand, a transport switch need only to map ingress time- slots to egress time-slots and interfaces, and therefore can be considerably less complex.
On the other hand, a transport switch need only to map ingress time- slots to egress time-slots and interfaces, and therefore can be considerably less complex.
5.2.3. Hardware Complexity
5.2.3. Hardware Complexity
One measure of hardware complexity is the number of logic gates on a line card [MOLINERO2002]. Consider the case of a high-speed Internet router line card: An OC192 POS router line card contains at least 30 million gates in ASICs, at least one CPU, 300 Mbytes of packet buffers, 2 Mbytes of forwarding table, and 10 Mbytes of other
One measure of hardware complexity is the number of logic gates on a line card [MOLINERO2002]. Consider the case of a high-speed Internet router line card: An OC192 POS router line card contains at least 30 million gates in ASICs, at least one CPU, 300 Mbytes of packet buffers, 2 Mbytes of forwarding table, and 10 Mbytes of other
Bush, et. al. Informational [Page 15] RFC 3439 Internet Architectural Guidelines December 2002
Bush, et. al. Informational [Page 15] RFC 3439 Internet Architectural Guidelines December 2002
state memory. On the other hand, a comparable transport switch line card has 7.5 million logic gates, no CPU, no packet buffer, no forwarding table, and an on-chip state memory. Rather, the line-card of an electronic transport switch typically contains a SONET framer, a chip to map ingress time-slots to egress time-slots, and an interface to the switch fabric.
state memory. On the other hand, a comparable transport switch line card has 7.5 million logic gates, no CPU, no packet buffer, no forwarding table, and an on-chip state memory. Rather, the line-card of an electronic transport switch typically contains a SONET framer, a chip to map ingress time-slots to egress time-slots, and an interface to the switch fabric.
5.2.4. Power
5.2.4. Power
Since transport switches have traditionally been built from simpler hardware components, they also consume less power [PMC].
Since transport switches have traditionally been built from simpler hardware components, they also consume less power [PMC].
5.2.5. Density
5.2.5. Density
The highest capacity transport switches have about four times the capacity of an IP router [CISCO,CIENA], and sell for about one-third as much per Gigabit/sec. Optical (OOO) technology pushes this complexity difference further (e.g., tunable lasers, MEMs switches. e.g., [CALIENT]), and DWDM multiplexers provide technology to build extremely high capacity, low power transport switches.
The highest capacity transport switches have about four times the capacity of an IP router [CISCO,CIENA], and sell for about one-third as much per Gigabit/sec. Optical (OOO) technology pushes this complexity difference further (e.g., tunable lasers, MEMs switches. e.g., [CALIENT]), and DWDM multiplexers provide technology to build extremely high capacity, low power transport switches.
A related metric is physical footprint. In general, by virtue of their higher density, transport switches have a smaller "per-gigabit" physical footprint.
A related metric is physical footprint. In general, by virtue of their higher density, transport switches have a smaller "per-gigabit" physical footprint.
5.2.6. Fixed versus variable costs
5.2.6. Fixed versus variable costs
Packet switching would seem to have high variable cost, meaning that it costs more to send the n-th piece of information using packet switching than it might in a circuit switched network. Much of this advantage is due to the relatively static nature of circuit switching, e.g., circuit switching can take advantage of of pre- scheduled arrival of information to eliminate operations to be performed on incoming information. For example, in the circuit switched case, there is no need to buffer incoming information, perform loop detection, resolve next hops, modify fields in the packet header, and the like. Finally, many circuit switched networks combine relatively static configuration with out-of-band control planes (e.g., SS7), which greatly simplifies data-plane switching. The bottom line is that as data rates get large, it becomes more and more complex to switch packets, while circuit switching scales more or less linearly.
Packet switching would seem to have high variable cost, meaning that it costs more to send the n-th piece of information using packet switching than it might in a circuit switched network. Much of this advantage is due to the relatively static nature of circuit switching, e.g., circuit switching can take advantage of of pre- scheduled arrival of information to eliminate operations to be performed on incoming information. For example, in the circuit switched case, there is no need to buffer incoming information, perform loop detection, resolve next hops, modify fields in the packet header, and the like. Finally, many circuit switched networks combine relatively static configuration with out-of-band control planes (e.g., SS7), which greatly simplifies data-plane switching. The bottom line is that as data rates get large, it becomes more and more complex to switch packets, while circuit switching scales more or less linearly.
Bush, et. al. Informational [Page 16] RFC 3439 Internet Architectural Guidelines December 2002
Bush, et. al. Informational [Page 16] RFC 3439 Internet Architectural Guidelines December 2002
5.2.7. QoS
5.2.7. QoS
While the components of a complete solution for Internet QoS, including call admission control, efficient packet classification, and scheduling algorithms, have been the subject of extensive research and standardization for more than 10 years, end-to-end signaled QoS for the Internet has not become a reality. Alternatively, QoS has been part of the circuit switched infrastructure almost from its inception. On the other hand, QoS is usually deployed to determine queuing disciplines to be used when there is insufficient bandwidth to support traffic. But unlike voice traffic, packet drop or severe delay may have a much more serious effect on TCP traffic due to its congestion-aware feedback loop (in particular, TCP backoff/slow start).
While the components of a complete solution for Internet QoS, including call admission control, efficient packet classification, and scheduling algorithms, have been the subject of extensive research and standardization for more than 10 years, end-to-end signaled QoS for the Internet has not become a reality. Alternatively, QoS has been part of the circuit switched infrastructure almost from its inception. On the other hand, QoS is usually deployed to determine queuing disciplines to be used when there is insufficient bandwidth to support traffic. But unlike voice traffic, packet drop or severe delay may have a much more serious effect on TCP traffic due to its congestion-aware feedback loop (in particular, TCP backoff/slow start).
5.2.8. Flexibility
5.2.8. Flexibility
A somewhat harder to quantify metric is the inherent flexibility of the Internet. While the Internet's flexibility has led to its rapid growth, this flexibility comes with a relatively high cost at the edge: the need for highly trained support personnel. A standard rule of thumb is that in an enterprise setting, a single support person suffices to provide telephone service for a group, while you need ten computer networking experts to serve the networking requirements of the same group [ODLYZKO98A]. This phenomenon is also described in [PERROW].
A somewhat harder to quantify metric is the inherent flexibility of the Internet. While the Internet's flexibility has led to its rapid growth, this flexibility comes with a relatively high cost at the edge: the need for highly trained support personnel. A standard rule of thumb is that in an enterprise setting, a single support person suffices to provide telephone service for a group, while you need ten computer networking experts to serve the networking requirements of the same group [ODLYZKO98A]. This phenomenon is also described in [PERROW].
5.3. Relative Complexity
5.3. Relative Complexity
The relative computational complexity of circuit switching as compared to packet switching has been difficult to describe in formal terms [PARK]. As such, the sections above seek to describe the complexity in terms of observable artifacts. With this in mind, it is clear that the fundamental driver producing the increased complexities outlined above is the hop-by-hop independence (HBHI) inherent in the IP architecture. This is in contrast to the end to end architectures such as ATM or Frame Relay.
The relative computational complexity of circuit switching as compared to packet switching has been difficult to describe in formal terms [PARK]. As such, the sections above seek to describe the complexity in terms of observable artifacts. With this in mind, it is clear that the fundamental driver producing the increased complexities outlined above is the hop-by-hop independence (HBHI) inherent in the IP architecture. This is in contrast to the end to end architectures such as ATM or Frame Relay.
[WILLINGER2002] describes this phenomenon in terms of the robustness requirement of the original Internet design, and how this requirement has the driven complexity of the network. In particular, they describe a "complexity/robustness" spiral, in which increases in complexity create further and more serious sensitivities, which then requires additional robustness (hence the spiral).
[WILLINGER2002] describes this phenomenon in terms of the robustness requirement of the original Internet design, and how this requirement has the driven complexity of the network. In particular, they describe a "complexity/robustness" spiral, in which increases in complexity create further and more serious sensitivities, which then requires additional robustness (hence the spiral).
Bush, et. al. Informational [Page 17] RFC 3439 Internet Architectural Guidelines December 2002
Bush, et. al. Informational [Page 17] RFC 3439 Internet Architectural Guidelines December 2002
The important lesson of this section is that the Simplicity Principle, while applicable to circuit switching as well as packet switching, is crucial in controlling the complexity (and hence OPEX and CAPEX properties) of packet networks. This idea is reinforced by the observation that while packet switching is a younger, less mature discipline than circuit switching, the trend in packet switches is toward more complex line cards, while the complexity of circuit switches appears to be scaling linearly with line rates and aggregate capacity.
The important lesson of this section is that the Simplicity Principle, while applicable to circuit switching as well as packet switching, is crucial in controlling the complexity (and hence OPEX and CAPEX properties) of packet networks. This idea is reinforced by the observation that while packet switching is a younger, less mature discipline than circuit switching, the trend in packet switches is toward more complex line cards, while the complexity of circuit switches appears to be scaling linearly with line rates and aggregate capacity.
5.3.1. HBHI and the OPEX Challenge
5.3.1. HBHI and the OPEX Challenge
As a result of HBHI, we need to approach IP networks in a fundamentally different way than we do circuit based networks. In particular, the major OPEX challenge faced by the IP network is that debugging of a large-scale IP network still requires a large degree of expertise and understanding, again due to the hop-by-hop independence inherent in a packet architecture (again, note that this hop-by-hop independence is not present in virtual circuit networks such as ATM or Frame Relay). For example, you may have to visit a large set of your routers only to discover that the problem is external to your own network. Further, the debugging tools used to diagnose problems are also complex and somewhat primitive. Finally, IP has to deal with people having problems with their DNS or their mail or news or some new application, whereas this is usually not the case for TDM/ATM/etc. In the case of IP, this can be eased by improving automation (note that much of what we mention is customer facing). In general, there are many variables external to the network that effect OPEX.
As a result of HBHI, we need to approach IP networks in a fundamentally different way than we do circuit based networks. In particular, the major OPEX challenge faced by the IP network is that debugging of a large-scale IP network still requires a large degree of expertise and understanding, again due to the hop-by-hop independence inherent in a packet architecture (again, note that this hop-by-hop independence is not present in virtual circuit networks such as ATM or Frame Relay). For example, you may have to visit a large set of your routers only to discover that the problem is external to your own network. Further, the debugging tools used to diagnose problems are also complex and somewhat primitive. Finally, IP has to deal with people having problems with their DNS or their mail or news or some new application, whereas this is usually not the case for TDM/ATM/etc. In the case of IP, this can be eased by improving automation (note that much of what we mention is customer facing). In general, there are many variables external to the network that effect OPEX.
Finally, it is important to note that the quantitative relationship between CAPEX, OPEX, and a network's inherent complexity is not well understood. In fact, there are no agreed upon and quantitative metrics for describing a network's complexity, so a precise relationship between CAPEX, OPEX, and complexity remains elusive.
Finally, it is important to note that the quantitative relationship between CAPEX, OPEX, and a network's inherent complexity is not well understood. In fact, there are no agreed upon and quantitative metrics for describing a network's complexity, so a precise relationship between CAPEX, OPEX, and complexity remains elusive.
6. The Myth of Over-Provisioning
6. The Myth of Over-Provisioning
As noted in [MC2001] and elsewhere, much of the complexity we observe in today's Internet is directed at increasing bandwidth utilization. As a result, the desire of network engineers to keep network utilization below 50% has been termed "over-provisioning". However, this use of the term over-provisioning is a misnomer. Rather, in modern Internet backbones the unused capacity is actually protection capacity. In particular, one might view this as "1:1 protection at the IP layer". Viewed in this way, we see that an IP network provisioned to run at 50% utilization is no more over-provisioned than the typical SONET network. However, the important advantages
As noted in [MC2001] and elsewhere, much of the complexity we observe in today's Internet is directed at increasing bandwidth utilization. As a result, the desire of network engineers to keep network utilization below 50% has been termed "over-provisioning". However, this use of the term over-provisioning is a misnomer. Rather, in modern Internet backbones the unused capacity is actually protection capacity. In particular, one might view this as "1:1 protection at the IP layer". Viewed in this way, we see that an IP network provisioned to run at 50% utilization is no more over-provisioned than the typical SONET network. However, the important advantages
Bush, et. al. Informational [Page 18] RFC 3439 Internet Architectural Guidelines December 2002
Bush, et. al. Informational [Page 18] RFC 3439 Internet Architectural Guidelines December 2002
that accrue to an IP network provisioned in this way include close to speed of light delay and close to zero packet loss [FRALEIGH]. These benefits can been seen as a "side-effect" of 1:1 protection provisioning.
that accrue to an IP network provisioned in this way include close to speed of light delay and close to zero packet loss [FRALEIGH]. These benefits can been seen as a "side-effect" of 1:1 protection provisioning.
There are also other, system-theoretic reasons for providing 1:1-like protection provisioning. Most notable among these reasons is that packet-switched networks with in-band control loops can become unstable and can experience oscillations and synchronization when congested. Complex and non-linear dynamic interaction of traffic means that congestion in one part of the network will spread to other parts of the network. When routing protocol packets are lost due to congestion or route-processor overload, it causes inconsistent routing state, and this may result in traffic loops, black holes, and lost connectivity. Thus, while statistical multiplexing can in theory yield higher network utilization, in practice, to maintain consistent performance and a reasonably stable network, the dynamics of the Internet backbones favor 1:1 provisioning and its side effects to keep the network stable and delay low.
There are also other, system-theoretic reasons for providing 1:1-like protection provisioning. Most notable among these reasons is that packet-switched networks with in-band control loops can become unstable and can experience oscillations and synchronization when congested. Complex and non-linear dynamic interaction of traffic means that congestion in one part of the network will spread to other parts of the network. When routing protocol packets are lost due to congestion or route-processor overload, it causes inconsistent routing state, and this may result in traffic loops, black holes, and lost connectivity. Thus, while statistical multiplexing can in theory yield higher network utilization, in practice, to maintain consistent performance and a reasonably stable network, the dynamics of the Internet backbones favor 1:1 provisioning and its side effects to keep the network stable and delay low.
7. The Myth of Five Nines
7. The Myth of Five Nines
Paul Baran, in his classic paper, "SOME PERSPECTIVES ON NETWORKS-- PAST, PRESENT AND FUTURE", stated that "The tradeoff curves between cost and system reliability suggest that the most reliable systems might be built of relatively unreliable and hence low cost elements, if it is system reliability at the lowest overall system cost that is at issue" [BARAN77].
Paul Baran, in his classic paper, "SOME PERSPECTIVES ON NETWORKS-- PAST, PRESENT AND FUTURE", stated that "The tradeoff curves between cost and system reliability suggest that the most reliable systems might be built of relatively unreliable and hence low cost elements, if it is system reliability at the lowest overall system cost that is at issue" [BARAN77].
Today we refer to this phenomenon as "the myth of five nines". Specifically, so-called five nines reliability in packet network elements is consider a myth for the following reasons: First, since 80% of unscheduled outages are caused by people or process errors [SCOTT], there is only a 20% window in which to optimize. Thus, in order to increase component reliability, we add complexity (optimization frequently leads to complexity), which is the root cause of 80% of the unplanned outages. This effectively narrows the 20% window (i.e., you increase the likelihood of people and process failure). This phenomenon is also characterized as a "complexity/robustness" spiral [WILLINGER2002], in which increases in complexity create further and more serious sensitivities, which then requires additional robustness, and so on (hence the spiral).
今日、私たちは「5時9分の神話」とこの現象を呼びます。 明確にいわゆる5、パケット網要素の9の信頼性は以下の理由でa神話を考えることです: 人々か過程誤り[スコット]で80%の予定外の供給停止が引き起こされるので、まず最初に、最適化する20%の窓しかありません。 したがって、私たちは、コンポーネントの信頼性を増加させるように、複雑さ(最適化は頻繁に複雑さにつながる)を加えます。(それは、無計画な供給停止の80%の根本的原因です)。 事実上、これは20%の窓を狭くします(すなわち、あなたは人々と過程の失敗の可能性を広げます)。 また、この現象は「複雑さ/丈夫さ」複雑さのどの増加がその時が必要とする一層の、そして、より重大な敏感さを作成するかのらせん状[WILLINGER2002]の追加丈夫さなど(したがって、らせん)として特徴付けられます。
The conclusion, then is that while a system like the Internet can reach five-nines-like reliability, it is undesirable (and likely impossible) to try to make any individual component, especially the most complex ones, reach that reliability standard.
結論であり、インターネットのようなシステムに達することができますが、その時、それがいる、5、9のようである、信頼性、どんな個々のコンポーネント、特に最も複雑なものも作ろうとするのが望ましくない、そして、(おそらく不可能)であり、その信頼性の規格に達してください。
Bush, et. al. Informational [Page 19] RFC 3439 Internet Architectural Guidelines December 2002
etブッシュ、アル。 ガイドライン2002年12月に建築している情報[19ページ]のRFC3439インターネット
8. Architectural Component Proportionality Law
8. 建築コンポーネント比例性法
As noted in the previous section, the computational complexity of packet switched networks such as the Internet has proven difficult to describe in formal terms. However, an intuitive, high level definition of architectural complexity might be that the complexity of an architecture is proportional to its number of components, and that the probability of achieving a stable implementation of an architecture is inversely proportional to its number of components. As described above, components include discrete elements such as hardware elements, space and power requirements, as well as software, firmware, and the protocols they implement.
前項で注意されるように、インターネットなどのパケット交換網の計算量は正式な用語で説明するのが難しいと判明しました。しかしながら、建築複雑さの直感的で、高い平らな定義は構造の複雑さがコンポーネントの番号に比例していて、構造の安定した実現を達成するという確率が逆にコンポーネントの番号に変化しているということであるかもしれません。 上で説明されるように、コンポーネントはハードウェア要素や、スペースや所要電力などの離散的な要素を含んでいます、それらが実行するソフトウェア、ファームウェア、およびプロトコルと同様に。
Stated more abstractly:
より抽象的に述べられています:
Let
貸されます。
A be a representation of architecture A,
構造Aの表現になってください。
|A| be number of distinct components in the service
delivery path of architecture A,
| A| 異なったコンポーネントの数が構造Aのサービス配送経路にあります。
w be a monotonically increasing function,
w、単調に増加する機能になってください。
P be the probability of a stable implementation of an
architecture, and let
構造の安定した実現の確率であり、貸されたP
Then
その時
Complexity(A) = O(w(|A|))
P(A) = O(1/w(|A|))
Complexity(A)=O(w(| A|))P(A)はOと等しいです。(1/w(| A|))
where
どこ
O(f) = {g:N->R | there exists c > 0 and n such that g(n)
< c*f(n)}
O(f)=g: N>R|、c>0とnが存在している、そのようなもの、そのg(n)<c*f(n)
[That is, O(f) comprises the set of functions g for which
there exists a constant c and a number n, such that g(n) is
smaller or equal to c*f(n) for all n. That is, O(f) is the
set of all functions that do not grow faster than f,
disregarding constant factors]
[すなわち、O(f)は定数cとNo.nが存在する機能gのセットを包括します、すべてのnに、g(n)がc*f(n)と、より小さいか、または等しいように。 すなわち、O(f)は恒常的要因を無視して、fより速くなるというわけではないすべての機能のセットです。]
Interestingly, the Highly Optimized Tolerance (HOT) model [HOT] attempts to characterize complexity in general terms (HOT is one recent attempt to develop a general framework for the study of complexity, and is a member of a family of abstractions generally termed "the new science of complexity" or "complex adaptive
おもしろく、Highly Optimized Tolerance(HOT)モデル[HOT]が、あいまいな言葉で複雑さを特徴付けるのを試みる、(HOTが複雑さの研究に一般的な枠組みを開発するある最近の試みであり、抽象化の家族のメンバーは、一般に、「複雑さの新しい科学」と呼ばれるか、または「複合体適応型です」。
Bush, et. al. Informational [Page 20] RFC 3439 Internet Architectural Guidelines December 2002
etブッシュ、アル。 ガイドライン2002年12月に建築している情報[20ページ]のRFC3439インターネット
systems"). Tolerance, in HOT semantics, means that "robustness in complex systems is a constrained and limited quantity that must be carefully managed and protected." One focus of the HOT model is to characterize heavy-tailed distributions such as Complexity(A) in the above example (other examples include forest fires, power outages, and Internet traffic distributions). In particular, Complexity(A) attempts to map the extreme heterogeneity of the parts of the system (Internet), and the effect of their organization into highly structured networks, with hierarchies and multiple scales.
「システム」) HOT意味論では、寛容は、「複合システムにおける丈夫さは慎重に管理されて、保護しなければならない強制的で限られた量です。」と意味します。 HOTモデルの1つの焦点が上記の例のComplexity(A)などの悪党尾をした配を特徴付けることになっています(他の例は山火事、電力供給停止、およびインターネットトラフィック配を含んでいます)。 特に、Complexity(A)は、システム(インターネット)の部分の極端な異種性、および彼らの組織の効果を非常に構造化されたネットワークに写像するのを試みます、階層構造と多重目盛で。
8.1. Service Delivery Paths
8.1. サービス配送経路
The Architectural Component Proportionality Law (ACPL) states that the complexity of an architecture is proportional to its number of components.
Architectural Component Proportionality法(ACPL)は、構造の複雑さがコンポーネントの番号に比例していると述べます。
COROLLARY: Minimize the number of components in a service delivery path, where the service delivery path can be a protocol path, a software path, or a physical path.
推論: サービス配送経路のコンポーネントの数を最小にしてください。(そこでは、サービス配送経路は、プロトコル経路、ソフトウェア経路、または物理的な経路であるかもしれません)。
This corollary is an important consequence of the ACPL, as the path between a customer and the desired service is particularly sensitive to the number and complexity of elements in the path. This is due to the fact that the complexity "smoothing" that we find at high levels of aggregation [ZHANG] is missing as you move closer to the edge, as well as having complex interactions with backoffice and CRM systems. Examples of architectures that haven't found a market due to this effect include TINA-based CRM systems, CORBA/TINA based service architectures. The basic lesson here was that the only possibilities for deploying these systems were "Limited scale deployments (such) as in Starvision can avoid coping with major unproven scalability issues", or "Otherwise need massive investments (like the carrier- grade ORB built almost from scratch)" [TINA]. In other words, these systems had complex service delivery paths, and were too complex to be feasibly deployed.
この推論はACPLの重要な結果です、顧客と必要なサービスの間の経路が特に経路における、要素の数と複雑さに敏感であるときに。 これはあなたがbackofficeとの複雑な相互作用とCRMシステムを持っていることと同様に縁の、より近くに移るとき私たちが高いレベルの集合[チャン]で見つける複雑さ「スムージング」がなくなるという事実のためです。この効果のため買い手が付いていない構造に関する例はティナベースのCRMシステムを含んで、CORBA/ティナはサービス構造を基礎づけました。 これらのシステムを配備するための唯一の可能性が「制限されて、Starvisionで主要な立証されなかったスケーラビリティ問題に対処するのを避けることができるように展開(そのようなもの)をスケーリングしてください」ということであった、または「そうでなければ、大規模投資(キャリヤーグレードORBがほぼ最初から建てたように)を必要とする」という[ティナ]基本的なレッスンは、ここにありました。 言い換えれば、これらのシステムは、複雑なサービス配送経路を持って、実行できるように配備できないくらい複雑でした。
9. Conclusions
9. 結論
This document attempts to codify long-understood Internet architectural principles. In particular, the unifying principle described here is best expressed by the Simplicity Principle, which states complexity must be controlled if one hopes to efficiently scale a complex object. The idea that simplicity itself can lead to some form of optimality has been a common theme throughout history, and has been stated in many other ways and along many dimensions. For example, consider the maxim known as Occam's Razor, which was formulated by the medieval English philosopher and Franciscan monk William of Ockham (ca. 1285-1349), and states "Pluralitas non est
このドキュメントは、長く理解されているインターネット建築原則を成文化するのを試みます。 特に、Simplicity Principleがここで説明された統一原則を言い表すのは、最も良いです。(Simplicity Principleは人が、効率的に複雑な物をスケーリングすることを望んでいるなら複雑さを制御しなければならないと述べます)。 簡単さ自体が何らかのフォームの最適につながることができるという考えは、歴史の間中一般的なテーマであり、他の多くの道と多くの寸法に沿って述べられています。 例えば、オッカムの中世のイギリス人の哲学者とフランシスコ会修道士のウィリアムによって定式化されたOccamのレイザーとして知られている格言を考えてください。(ca。 1285-1349), そして、州の「Pluralitas非est」
Bush, et. al. Informational [Page 21] RFC 3439 Internet Architectural Guidelines December 2002
etブッシュ、アル。 ガイドライン2002年12月に建築している情報[21ページ]のRFC3439インターネット
ponenda sine neccesitate" or "plurality should not be posited without necessity." (hence Occam's Razor is sometimes called "the principle of unnecessary plurality" and " the principle of simplicity"). A perhaps more contemporary formulation of Occam's Razor states that the simplest explanation for a phenomenon is the one preferred by nature. Other formulations of the same idea can be found in the KISS (Keep It Simple Stupid) principle and the Principle of Least Astonishment (the assertion that the most usable system is the one that least often leaves users astonished). [WILLINGER2002] provides a more theoretical discussion of "robustness through simplicity", and in discussing the PSTN, [KUHN87] states that in most systems, "a trade-off can be made between simplicity of interactions and looseness of coupling".
「ponenda正弦はneccesitateする」か、または「必要性なしで多数を置くべきではありません」。 (したがって、Occamのレイザーは時々「不要な多数の原則と簡単さの原理」と呼ばれます。) 恐らくより現代の定式化、Occamのものでは、レイザーは、現象のための最も簡単な説明が生来、好まれたものであると述べます。 KISS(It Simple Stupidを保つ)原則とLeast AstonishmentのPrinciple(最も使用可能なシステムがユーザが驚いて最もしばしば残すものであるという主張)で同じ考えの他の定式化を見つけることができます。 [WILLINGER2002]は「簡単さを通した丈夫さ」の、より理論上の議論を前提とします、そして、PSTNについて議論する際に、[KUHN87]はほとんどのシステムでは、「相互作用の簡単さとカップリングのゆるみの間でトレードオフをすることができる」と述べます。
When applied to packet switched network architectures, the Simplicity Principle has implications that some may consider heresy, e.g., that highly converged approaches are likely to be less efficient than "less converged" solutions. Otherwise stated, the "optimal" convergence layer may be much lower in the protocol stack that is conventionally believed. In addition, the analysis above leads to several conclusions that are contrary to the conventional wisdom surrounding packet networking. Perhaps most significant is the belief that packet switching is simpler than circuit switching. This belief has lead to conclusions such as "since packet is simpler than circuit, it must cost less to operate". This study finds to the contrary. In particular, by examining the metrics described above, we find that packet switching is more complex than circuit switching. Interestingly, this conclusion is borne out by the fact that normalized OPEX for data networks is typically significantly greater than for voice networks [ML2002].
パケット交換網構造に適用されると、Simplicity Principleには、或るものが異端を考えるかもしれなくて、例えば、非常に一点に集められたアプローチが「それほど一点に集められなかった」解決策ほど効率的でない傾向があるという意味があります。 別の方法で述べられていて、「最適」の集合層は慣習上信じられているプロトコル・スタックではるかに低いかもしれません。 添加、一般通念の周辺パケットネットワークに合わないいくつかの結論への先導を超えた分析で。 恐らく最も重要であるのは、パケット交換が回線交換より簡単であるという信念です。 この信念は「パケットがサーキットより簡単であるので、作動するのは以下かからなければならないことなど」の結論にリードを持っています。 これはそれと反対に掘り出し物を研究します。 上で説明された測定基準を調べることによって、特に、私たちは、パケット交換が回線交換より複雑であることがわかりました。 通常、データ網のための正常にされたOPEXが声のネットワーク[ML2002]よりかなりすばらしいという事実によっておもしろく、この結論は証明されます。
Finally, the important conclusion of this work is that for packet networks that are of the scale of today's Internet or larger, we must strive for the simplest possible solutions if we hope to build cost effective infrastructures. This idea is eloquently stated in [DOYLE2002]: "The evolution of protocols can lead to a robustness/complexity/fragility spiral where complexity added for robustness also adds new fragilities, which in turn leads to new and thus spiraling complexities". This is exactly the phenomenon that the Simplicity Principle is designed to avoid.
最終的に、この仕事の重要な結論は費用効率がよいインフラストラクチャを築き上げることを望んでいるなら今日のインターネットのスケールがあるか、または、より大きいパケット網のために私たちが可能な限り簡単な解決策を求めて努力しなければならないということです。 この考えは[DOYLE2002]に雄弁に述べられています: 「また、丈夫さのために加えられた複雑さが新しいもろさを加えるところでプロトコルの発展は丈夫さ/複雑さ/もろさらせんに通じることができます(順番に新しくてその結果、らせん形になっている複雑さに通じます)。」 これはちょうどSimplicity Principleが避けるように設計されている現象です。
10. Security Considerations
10. セキュリティ問題
This document does not directly effect the security of any existing Internet protocol. However, adherence to the Simplicity Principle does have a direct affect on our ability to implement secure systems. In particular, a system's complexity grows, it becomes more difficult to model and analyze, and hence it becomes more difficult
このドキュメントは直接どんな既存のインターネットプロトコルのセキュリティにも作用しません。 しかしながら、Simplicity Principleへの固守は安全なシステムを導入する私たちの能力にダイレクト感情を持っています。特に、システムの複雑さは成長します、そして、モデル化して、分析するのが、より難しくなります、そして、したがって、それは、より難しくなります。
Bush, et. al. Informational [Page 22] RFC 3439 Internet Architectural Guidelines December 2002
etブッシュ、アル。 ガイドライン2002年12月に建築している情報[22ページ]のRFC3439インターネット
to find and understand the security implications inherent in its architecture, design, and implementation.
構造、デザイン、および実現の固有であるセキュリティ含意を見つけて、理解するために。
11. Acknowledgments
11. 承認
Many of the ideas for comparing the complexity of circuit switched and packet switched networks were inspired by conversations with Nick McKeown. Scott Bradner, David Banister, Steve Bellovin, Steward Bryant, Christophe Diot, Susan Harris, Ananth Nagarajan, Andrew Odlyzko, Pete and Natalie Whiting, and Lixia Zhang made many helpful comments on early drafts of this document.
サーキットの複雑さを比較するための考えの多くが切り替わりました、そして、パケット交換網はニック・マキューンとの会話で奮い立たせられました。 スコット・ブラドナー、デヴィッドBanister、スティーブBellovin、Stewardブライアント、クリストフDiot、スーザン・ハリス、Ananth Nagarajan、アンドリューOdlyzko、ピート、ナタリー・ホワイティング、およびLixiaチャンはこのドキュメントの早めの草稿の多くの役に立つコメントをしました。
12. References
12. 参照
[AHUJA] "The Impact of Internet Policy and Topology on
Delayed Routing Convergence", Labovitz, et. al.
Infocom, 2001.
[AHUJA] et「遅れたルート設定集合へのインターネット方針とトポロジーの影響」、Labovitz、アル。 Infocom、2001。
[ATMMPLS] "ATM-MPLS Interworking Migration Complexities Issues
and Preliminary Assessment", School of
Interdisciplinary Computing and Engineering,
University of Missouri-Kansas City, April 2002
[ATMMPLS] 「移動の複雑さが問題と初期評価であると織り込む気圧-MPLS」と学際のコンピューティングの学校と工学、ミズーリ-カンザスシティー大学、2002年4月
[BARAN] "On Distributed Communications", Paul Baran, Rand
Corporation Memorandum RM-3420-PR,
http://www.rand.org/publications/RM/RM3420", August,
1964.
1964年8月の「「分配されたコミュニケーション」の[バラン]、ポール・バラン、米空軍の委託研究機関メモRM3420PR、 http://www.rand.org/publications/RM/RM3420 」
[BARAN77] "SOME PERSPECTIVES ON NETWORKS--PAST, PRESENT AND
FUTURE", Paul Baran, Information Processing 77,
North-Holland Publishing Company, 1977,
[BARAN77] ポール・バラン、情報処理77、北のオランダが会社、1977を発行することでの「過去の、そして、現在の、そして、将来のネットワークのいくつかの見解」
[BRYANT] "Protocol Layering in PWE3", Bryant et al, Work in
Progress.
[ブライアント] 「PWE3"で層にされるプロトコル、ブライアント他は進行中で働いています」。
[CAIDA] http://www.caida.org
[CAIDA] http://www.caida.org
[CALLIENT] http://www.calient.net/home.html
[CALLIENT] http://www.calient.net/home.html
[CARLSON] "Complexity and Robustness", J.M. Carlson and John
Doyle, Proc. Natl. Acad. Sci. USA, Vol. 99, Suppl. 1,
2538-2545, February 19, 2002.
http://www.pnas.org/cgi/doi/10.1073/pnas.012582499
[カールソン] 「複雑さと丈夫さ」、J.M.カールソンとジョン・ドイル、Proc。 Natl。 Acad。 Sci。 米国、Vol.99、Suppl。 1 2538 2545年2月19日、2002 http://www.pnas.org/cgi/doi/10.1073/pnas.012582499
[CIENA] "CIENA Multiwave CoreDiretor",
http://www.ciena.com/downloads/products/
coredirector.pdf
[CIENA] "CIENA Multiwave CoreDiretor"、 http://www.ciena.com/downloads/products/ coredirector.pdf
Bush, et. al. Informational [Page 23] RFC 3439 Internet Architectural Guidelines December 2002
etブッシュ、アル。 ガイドライン2002年12月に建築している情報[23ページ]のRFC3439インターネット
[CISCO] http://www.cisco.com
[シスコ] http://www.cisco.com
[CLARK] "The Design Philosophy of the DARPA Internet
Protocols", D. Clark, Proc. of the ACM SIGCOMM, 1988.
[クラーク] 「DARPAインターネットプロトコルの設計理念」、D.クラーク、Proc、ACM SIGCOMM、1988年について。
[COFFMAN] "Internet Growth: Is there a 'Moores Law' for Data
Traffic", K.G. Coffman and A.M. Odlyzko, pp. 47-93,
Handbook of Massive Data Stes, J. Elli, P. M.
Pardalos, and M. G. C. Resende, Editors. Kluwer,
2002.
[コフマン]、「インターネットの成長:」 「Data Trafficのための'ムーア法'があっ」てK.G.コフマンと午前Odlyzko、ページ 47-93 大規模なデータStes、J.エッリ、P.M.Pardalos、およびM.G.C.レゼンデ、エディターズのハンドブック。 Kluwer、2002。
[DOYLE2002] "Robustness and the Internet: Theoretical
Foundations", John C. Doyle, et. al. Work in
Progress.
[DOYLE2002]、「丈夫さとインターネット:」 et「理論上の財団」、ジョン・C.ドイル、アル。 進行中で、働いてください。
[EICK] "Visualizing Software Changes", S.G. Eick, et al,
National Institute of Statistical Sciences, Technical
Report 113, December 2000.
[EICK] 「ソフトウェア変化を想像します」、S.G.Eick、他、Statistical Sciences、Technical Report113、2000年12月のNational Institute。
[MOLINERO2002] "TCP Switching: Exposing Circuits to IP", Pablo
Molinero-Fernandez and Nick McKeown, IEEE January,
2002.
[MOLINERO2002] 「以下を切り換えるTCP」 「サーキットをIPに露出します」とパブロ・Molinero-フェルナンデスとニック・マキューン、IEEE2002年1月。
[FLOYD] "The Synchronization of Periodic Routing Messages",
Sally Floyd and Van Jacobson, IEEE ACM Transactions
on Networking, 1994.
[フロイド] ネットワーク、1994における「周期的なルーティング・メッセージの同期」とSallyフロイドとバンジェーコブソン、IEEE ACM取引。
[FLOYD2001] "A Report on Some Recent Developments in TCP
Congestion Control, IEEE Communications Magazine, S.
Floyd, April 2001.
[FLOYD2001] 「TCP輻輳制御、IEEEコミュニケーション雑誌、S.フロイド、2001年4月のいくつかの最近の進展に関するレポート。」
[FRALEIGH] "Provisioning IP Backbone Networks to Support Delay-
Based Service Level Agreements", Chuck Fraleigh,
Fouad Tobagi, and Christophe Diot, 2002.
[フレイリー] 「遅れを支持するためにIP背骨ネットワークに食糧を供給すると、サービス・レベル・アグリーメントは基づいた」、チャック・フレイリー、Fouad Tobagi、およびクリストフDiot、2002。
[GRIFFIN] "What is the Sound of One Route Flapping", Timothy G.
Griffin, IPAM Workshop on Large-Scale Communication
Networks: Topology, Routing, Traffic, and Control,
March, 2002.
Large-スケールCommunication Networksの上の[グリフィン]「One Route FlappingのSoundは何です」、ティモシー・G.グリフィンIPAM Workshop: トポロジーとルート設定、交通とコントロール、2002年3月。
[HANDLEY] "On Inter-layer Assumptions (A view from the
Transport Area), slides from a presentation at the
IAB workshop on Wireless Internetworking", M.
Handley, March 2000.
「Wireless Internetworkingに関するIABワークショップでのプレゼンテーションからのInter-層のAssumptions(Transport Areaからの視点)、スライド」の[ハンドレー]、M.ハンドレー(2000年3月)
[HOT] J.M. Carlson and John Doyle, Phys. Rev. E 60, 1412-
1427, 1999.
[熱い] J.M.カールソンとジョン・ドイル、Phys。 60人のE師、1412- 1427、1999。
Bush, et. al. Informational [Page 24] RFC 3439 Internet Architectural Guidelines December 2002
etブッシュ、アル。 ガイドライン2002年12月に建築している情報[24ページ]のRFC3439インターネット
[ISO10589] "Intermediate System to Intermediate System
Intradomain Routing Exchange Protocol (IS-IS)".
[ISO10589]、「中間システムIntradomainルート設定交換プロトコルへの中間システム、(-、)、」
[JACOBSON] "Congestion Avoidance and Control", Van Jacobson,
Proceedings of ACM Sigcomm 1988, pp. 273-288.
[ジェーコブソン]「輻輳回避とコントロール」、ヴァン・ジェーコブソン、ACM Sigcomm1988のProceedings、ページ 273-288.
[KARN] "TCP vs Link Layer Retransmission" in P. Karn et al.,
Advice for Internet Subnetwork Designers, Work in
Progress.
[KARN] P.Karn他における「TCP対リンクレイヤRetransmission」、インターネットSubnetwork Designers、ProgressのWorkのためのAdvice。
[KUHN87] "Sources of Failure in the Public Switched Telephone
Network", D. Richard Kuhn, EEE Computer, Vol. 30, No.
4, April, 1997.
[KUHN87] 「公衆での失敗の源は電話網を切り換えました」、D.リチャード・キューン、EEEコンピュータ、Vol.30、No.4、1997年4月。
[L2TPV3] Lan, J., et. al., "Layer Two Tunneling Protocol
(Version 3) -- L2TPv3", Work in Progress.
[L2TPV3] etラン、J.、アル、「層Twoのトンネリングプロトコル(バージョン3)--L2TPv3"、進行中で、働いてください。」
[MC2001] "U.S Communications Infrastructure at A Crossroads:
Opportunities Amid the Gloom", McKinsey&Company for
Goldman-Sachs, August 2001.
[MC2001]、「交差点のU.S通信基盤:」 ゴールドマンサックス、2001年8月のための「暗闇の中に機会」、マッキンゼー、および会社。
[MCK2002] Nick McKeown, personal communication, April, 2002.
[MCK2002]はマキューン、個人的なコミュニケーションに2002年4月に傷を付けます。
[ML2002] "Optical Systems", Merril Lynch Technical Report,
April, 2002.
[ML2002]「光学系」、メリルリンチ技術報告書、2002年4月。
[NAVE] "The influence of mode coupling on the non-linear
evolution of tearing modes", M.F.F. Nave, et al, Eur.
Phys. J. D 8, 287-297.
[NAVE] 「裂け目のモードの非線形の発展へのモード結合の影響」、M.F.F.Nave、他、Eur。 Phys。 J。 D8、287-297。
[NEUMANN] "Cause of AT&T network failure", Peter G. Neumann,
http://catless.ncl.ac.uk/Risks/9.62.html#subj2
[ノイマン] 「AT&Tのネットワーク失敗の原因」、ピーター・G.ノイマン、 http://catless.ncl.ac.uk/Risks/9.62.html#subj2
[ODLYZKO] "Data networks are mostly empty for good reason",
A.M. Odlyzko, IT Professional 1 (no. 2), pp. 67-69,
Mar/Apr 1999.
[ODLYZKO] 「もっともな理由に、データ網はほとんど空である」午前Odlyzko、IT Professional1(No.2)、ページ 67-69と、1999年3月/4月。
[ODLYZKO98A] "Smart and stupid networks: Why the Internet is like
Microsoft". A. M. Odlyzko, ACM Networker, 2(5),
December, 1998.
[ODLYZKO98A] 「痛んでください。そうすれば、馬鹿は以下をネットワークでつなぎます」。 「インターネットはマイクロソフトに似ています。」 A。 M。 Odlyzko、ACMネットワーカ、2(5)、1998年12月。
[ODLYZKO98] "The economics of the Internet: Utility, utilization,
pricing, and Quality of Service", A.M. Odlyzko, July,
1998.
http://www.dtc.umn.edu/~odlyzko/doc/networks.html
[ODLYZKO98]、「インターネットの経済学:」 「Serviceのユーティリティ、利用、価格設定、およびQuality」、午前Odlyzko、7月、1998 http://www.dtc.umn.edu/~odlyzko/doc/networks.html
Bush, et. al. Informational [Page 25] RFC 3439 Internet Architectural Guidelines December 2002
etブッシュ、アル。 ガイドライン2002年12月に建築している情報[25ページ]のRFC3439インターネット
[PARK] "The Internet as a Complex System: Scaling,
Complexity and Control", Kihong Park and Walter
Willinger, AT&T Research, 2002.
[公園]、「複合システムとしてのインターネット:」 Kihong公園とウォルター・ウィリンジャー、AT&Tは、「スケーリング、複雑さ、およびコントロール」と2002に研究します。
[PERROW] "Normal Accidents: Living with High Risk
Technologies", Basic Books, C. Perrow, New York,
1984.
[ペロー]、「正常な事故:」 「ダーティー・ソルジャー/野良犬軍団技術がある生活」、基本的な本、C.ペロー、ニューヨーク、1984。
[PMC] "The Design of a 10 Gigabit Core Router
Architecture", PMC-Sierra, http://www.pmc-
sierra.com/products/diagrams/CoreRouter_lg.html
[PMC] 「10ギガビットコアルータ構造のデザイン」、PMC-連峰、 http://www.pmc- sierra.com/製品/ダイヤグラム/CoreRouter_lg.html
[RFC1629] Colella, R., Callon, R., Gardner, E. and Y. Rekhter,
"Guidelines for OSI NSAP Allocation in the Internet",
RFC 1629, May 1994.
[RFC1629] Colella、R.、Callon、R.、ガードナー、E.、およびY.Rekhter(「インターネットのオウシNSAP Allocationのためのガイドライン」、RFC1629)は1994がそうするかもしれません。
[RFC1925] Callon, R., "The Twelve Networking Truths", RFC 1925,
1 April 1996.
[RFC1925] Callon、R.、「12のネットワーク真」、RFC1925、1996年4月1日。
[RFC1958] Carpenter, B., Ed., "Architectural principles of the
Internet", RFC 1958, June 1996.
[RFC1958] 大工、B.、エド、「インターネットの建築原則」、RFC1958、6月1996日
[RFC2283] Bates, T., Chandra, R., Katz, D. and Y. Rekhter,
"Multiprotocol Extensions for BGP4", RFC 2283,
February 1998.
[RFC2283] ベイツとT.とチャンドラとR.とキャッツとD.とY.Rekhter、「BGP4"、RFC2283、1998年2月のためのMultiprotocol拡張子。」
[RFC3155] Dawkins, S., Montenegro, G., Kojo, M. and N. Vaidya,
"End-to-end Performance Implications of Links with
Errors", BCP 50, RFC 3155, May 2001.
[RFC3155] ダウキンズ、S.、モンテネグロ、G.、Kojo、M.、およびN.Vaidya(「終わりから終わりへの誤りとのリンクのパフォーマンス含意」、BCP50、RFC3155)は2001がそうするかもしれません。
[ROMANOV] "Dynamics of TCP over ATM Networks", A. Romanov, S.
Floyd, IEEE JSAC, vol. 13, No 4, pp.633-641, May
1995.
[ロマーノフ] 「気圧ネットワークの上のTCPの力学」、A.ロマーノフ、S.フロイド、IEEE JSAC、vol.13、4がない、pp.633-641、1995年5月。
[SALTZER] "End-To-End Arguments in System Design", J.H.
Saltzer, D.P. Reed, and D.D. Clark, ACM TOCS, Vol 2,
Number 4, November 1984, pp 277-288.
[SALTZER] 「システム設計における終わりから終わりへの議論」とJ.H.Saltzer、D.P.リードとD.D.クラーク、ACM TOCS Vol2、Number4、1984年11月、pp277-288。
[SCOTT] "Making Smart Investments to Reduce Unplanned
Downtime", D. Scott, Tactical Guidelines, TG-07-4033,
Gartner Group Research Note, March 1999.
[スコット] D.スコット、戦術のガイドライン、TG-07-4033、「無計画な休止時間を減少させるためにきびきびした投資をし」て、ガートナーグループは注意、1999年3月について研究します。
[SPILLMAN] "The Law of Diminishing Returns:, W. J. Spillman and
E. Lang, 1924.
[スピルマン]、「収穫逓減の法則:、W.J.スピルマンとE.ラング、1924インチ。
[STALLINGS] "Data and Computer Communications (2nd Ed)", William
Stallings, Maxwell Macmillan, 1989.
[ストーリング]「データとコンピュータコミュニケーション(第2エド)」、ウィリアム・ストーリングズ、マクスウェルマクミラン、1989。
Bush, et. al. Informational [Page 26] RFC 3439 Internet Architectural Guidelines December 2002
etブッシュ、アル。 ガイドライン2002年12月に建築している情報[26ページ]のRFC3439インターネット
[TENNENHOUSE] "Layered multiplexing considered harmful", D.
Tennenhouse, Proceedings of the IFIP Workshop on
Protocols for High-Speed Networks, Rudin ed., North
Holland Publishers, May 1989.
[TENNENHOUSE] 「有害であると考えられた層にされたマルチプレクシング」、D.Tennenhouse、High-速度Networks(ルーディン教育)、北部オランダPublishers(1989年5月)へのプロトコルのIFIP WorkshopのProceedings。
[THOMPSON] "Nonlinear Dynamics and Chaos". J.M.T. Thompson and
H.B. Stewart, John Wiley and Sons, 1994, ISBN
0471909602.
[トンプソン] 「非線形力学とカオス。」 J.M.T.トンプソンとH.B.スチュワートとジョン・ワイリーと息子、1994、ISBN0471909602
[TINA] "What is TINA and is it useful for the TelCos?",
Paolo Coppo, Carlo A. Licciardi, CSELT, EURESCOM
Participants in P847 (FT, IT, NT, TI)
[ティナ] 「ティナは者です、そして、それはTelCosの役に立ちますか?」、パオロCoppo、カルロA.Licciardi、CSELT、P847のEURESCOM Participants(フィート、IT、NT、TI)
[WAKEMAN] "Layering considered harmful", Ian Wakeman, Jon
Crowcroft, Zheng Wang, and Dejan Sirovica, IEEE
Network, January 1992, p. 7-16.
[ウェイクマン] 「有害であると考えられて、層にします」とイアン・ウェイクマンとジョン・クロウクロフト、ツェンワングとデヤンSirovica、IEEE Network、1992年1月、p。 7-16.
[WARD] "Custom fluorescent-nucleotide synthesis as an
alternative method for nucleic acid labeling",
Octavian Henegariu*, Patricia Bray-Ward and David C.
Ward, Nature Biotech 18:345-348 (2000).
[区]の「核酸ラベリングのための別法としての蛍光ヌクレオチド合成の習慣」とOctavian Henegariu*、パトリシア・Bray-ウォードとデヴィッド・C.ウォードネイチャーBiotech18: (345-348(2000))。
[WILLINGER2002] "Robustness and the Internet: Design and evolution",
Walter Willinger and John Doyle, 2002.
[WILLINGER2002]、「丈夫さとインターネット:」 「デザインと発展」、ウォルター・ウィリンジャーとジョン・ドイル、2002
[ZHANG] "Impact of Aggregation on Scaling Behavior of
Internet Backbone Traffic", Sprint ATL Technical
Report TR02-ATL-020157 Zhi-Li Zhang, Vinay Ribeiroj,
Sue Moon, Christophe Diot, February, 2002.
[チャン] 「インターネット背骨交通のスケーリングの振舞いの集合の影響」、スプリントのATL技術報告書TR02-ATL-020157 Zhi-李・チャン、ビナイRibeirojは月、クリストフDiot(2002年2月)を訴えます。
13. Authors' Addresses
13. 作者のアドレス
Randy Bush EMail: randy@psg.com
ランディブッシュEMail: randy@psg.com
David Meyer EMail: dmm@maoz.com
デヴィッドマイヤーEMail: dmm@maoz.com
Bush, et. al. Informational [Page 27] RFC 3439 Internet Architectural Guidelines December 2002
etブッシュ、アル。 ガイドライン2002年12月に建築している情報[27ページ]のRFC3439インターネット
14. Full Copyright Statement
14. 完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Bush, et. al. Informational [Page 28]
etブッシュ、アル。 情報[28ページ]
一覧
スポンサーリンク
