Internet Engineering Task Force (IETF) C. Bastian
Request for Comments: 6057 T. Klieber
Category: Informational J. Livingood
ISSN: 2070-1721 J. Mills
R. Woundy
Comcast
December 2010
Comcast's Protocol-Agnostic Congestion Management System
Abstract
抽象
This document describes the congestion management system of Comcast Cable, a large cable broadband Internet Service Provider (ISP) in the U.S. Comcast completed deployment of this congestion management system on December 31, 2008.
この文書では、Comcastのケーブルの輻輳管理システムを説明し、米国のComcastの大きいケーブルブロードバンドインターネットサービスプロバイダ（ISP）は2008年12月31日にこの輻輳管理システムの導入を完了しました。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6057.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6057で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................2
2. Applicability to Other Types of Networks ........................3
3. Key Terminology .................................................3
4. Historical Overview .............................................7
5. Summary .........................................................8
6. Relationship between Managing Congestion and Adding Capacity ....9
7. Implementation and Configuration ...............................10
7.1. Thresholds for Determining When a CMTS Port Is in a Near
Congestion State ..........................................14
7.2. Thresholds for Determining When a User Is in an
Extended High Consumption State and for Release from
That Classification .......................................15
7.3. Effect of BE Quality of Service on Users'
Broadband Experience ......................................19
7.4. Equipment/Software Used and Location ......................21
8. Conclusion .....................................................23
9. Exceptional Network Utilization Considerations .................23
10. Limitations of This Congestion Management System ..............24
11. Low Extra Delay Background Transport and Other Possibilities ..24
12. Security Considerations .......................................24
13. Acknowledgements ..............................................25
14. Informative References ........................................26
Comcast Cable is a large broadband Internet Service Provider (ISP), based in the U.S., serving the majority of its customers via cable modem technology. During the late part of 2008, and completing on December 31, 2008, Comcast deployed a new congestion management system across its entire network. This new system was developed in response to dissatisfaction in the Internet community as well as complaints to the U.S. Federal Communications Commission (FCC) regarding Comcast's old system, which targeted specific peer-to-peer (P2P) applications. This new congestion management system is protocol-agnostic, meaning that it does not examine or impact specific user applications or network protocols, which is perceived as a more fair system for managing network resources at limited times when congestion may occur.
Comcastのケーブルは、ケーブルモデム技術を介して、その顧客の大半を提供し、米国に拠点を置く大規模なブロードバンドインターネットサービスプロバイダ（ISP）、です。 2008年後半の一部、および2008年12月31日に完了した時には、Comcastはそのネットワーク全体の新しい輻輳管理システムを導入しました。この新しいシステムは、特定のピア・ツー・ピア（P2P）アプリケーションをターゲットとComcastの古いシステム、に関する米国連邦通信委員会（FCC）へのインターネットコミュニティでの不満や苦情に応えて開発されました。この新しい輻輳管理システムは、輻輳が発生する可能性が限られた時間で、ネットワークリソースを管理するための、より公正なシステムとして認識されている特定のユーザーのアプリケーションやネットワークプロトコルを、調べたり、影響を与えないことを意味し、プロトコルに依存しないです。
It is important for readers to note that congestion can occur in any IP network, and, when it does, packets can be delayed or dropped. As Bob Briscoe has pointed out on an IETF mailing list, some amount of packet loss can be normal and/or tolerable, noting "But a single TCP flow with a round trip time (RTT) of 80 ms can attain 50 Mbps with a loss fraction of 0.0013% (1 in ~74,000 packets) so there's no need to try to achieve loss figures much lower than this. And indeed, if flows aren't bottlenecked elsewhere, TCP will drive the system until it gets such loss levels. If, instead, a customer is downloading five separate 10 Mbps TCP flows still with an 80-ms RTT, TCP will drive losses up to 1 in ~3,000, or 0.03%, and any lower loss rates won't be able to improve performance". As a result, applications and protocols have been designed to deal with the reality that congestion can occur in any IP network, the mechanics of which we explain in detail later in this document.
それは、パケットが遅延またはドロップすることができないとき、読者はその輻輳が任意のIPネットワークで発生する可能性に注意することが重要である、と。ボブ・ブリスコーは、IETFメーリングリストで指摘したように、パケット損失のいくつかの量は、「注目し、正常なおよび/または許容することができますが、80ミリ秒のラウンドトリップ時間（RTT）を持つ単一のTCPフローは損失で50 Mbpsのを得ることができます0.0013パーセントの割合（1〜74000のパケットで）ので、これよりもはるかに低い。そして、フローは他の場所でボトルネックとされていない場合には、そのような損失のレベルを取得するまで実際に、TCPは、システムを駆動する損失の数値を達成しようとする必要はありません。もし代わりに、顧客が80ミリ秒のRTTでまだ5つの別々の10 MbpsのTCPフローをダウンロードして、TCPは「〜3,000で1までの損失を駆動、または0.03％、および任意の低損失率は、パフォーマンスを向上させることができなくなります。その結果、アプリケーションとプロトコルは、輻輳が、我々はこの文書の後半で詳しく説明力学うち、任意のIPネットワークで発生する可能性があることを現実に対処するように設計されています。
The purpose of this document is to describe how this example of a large-scale congestion management system functions. This is partially in response to questions from other ISPs as well as solution developers, who are interested in learning from and/or deploying similar systems in other networks. In addition, it is hoped that such a document may help inform new work in the IETF, in the hope that better systems and protocols may be possible in the future. Lastly, the authors wish to transparently and openly document this system, so that there could be no doubt about how the system functioned.
この文書の目的は、大規模な輻輳管理システムの機能のどのようにこの例を説明することです。これは、部分的に学び、および/または他のネットワークで同様のシステムを導入することに興味がある他のISPだけでなく、ソリューションの開発者からの質問に応じています。また、そのような文書は、より良いシステム及びプロトコルが将来的に可能であることを期待して、IETFで新しい仕事を知らせる役立つことが期待されます。最後に、著者は、システムが機能する方法についての疑いがあることができるように、透過的かつ公然と、このシステムを文書化したいです。
Several document reviewers and other IETF participants have pointed out that, though we refer to functional elements that are specific to a Data Over Cable Service Interface Specification (DOCSIS)-based network implementation, this type of congestion management system could be generally applied to nearly any type of network. Thus, it is important for readers to take note of this and take into consideration that this sort of protocol-agnostic congestion management system could certainly fit in a wide variety of network types and implementations.
いくつかの書類審査及びその他のIETFの参加者たちはデータオーバーケーブルサービスインターフェース仕様（DOCSIS）ベースのネットワークの実装に固有の機能要素を参照するのに、と指摘している、輻輳管理システムのこのタイプは、一般的にほぼすべてに適用することができネットワークの種類。読者は、このメモを取り、プロトコルに依存しない輻輳管理システムのこの種のは、確かにネットワークの種類と実装の多種多様に合うことができることを考慮に入れるためにこのように、それが重要です。
This section defines the key terms used in this document. Some terms below refer to elements of the Comcast network. As a result, it may be helpful to refer to Figure 1 (see Section 7) when reviewing some of these terms.
このセクションでは、このドキュメントで使用されている主要な用語を定義します。以下のいくつかの用語は、Comcastのネットワークの要素を参照してください。その結果、これらの用語のいくつかを検討するとき（第7節参照）。図1を参照するのに役立つことができます。
A device located at the customer premise used to access the Comcast High Speed Internet (HSI) network. In some cases, the cable modem is owned by the customer, and in other cases it is owned by the cable operator. This device has an interface (i.e., someplace to plug in a cable) for connecting the coaxial cable provided by the cable company to the modem, as well as one or more interfaces for connecting the modem to a customer's PC or home gateway device (e.g., home gateway, router, firewall, access point, etc.). In some cases, the cable modem function, i.e., the ability to access the Internet, is integrated into a home gateway device or Embedded Multimedia Terminal Adapter (eMTA). Once connected, the cable modem links the customer to the HSI network and ultimately the broader Internet.
Comcastの高速インターネット（HSI）ネットワークにアクセスするために使用する顧客宅内に設置デバイス。いくつかのケースでは、ケーブルモデムは、顧客によって所有され、それ以外の場合には、それは、ケーブル事業者が所有しています。このデバイスは、インタフェース、顧客のPCやホームゲートウェイ機器にモデムを接続するためのモデムにケーブルテレビ会社が提供する同軸ケーブルを接続するだけでなく、1つまたは複数のインターフェイスのために（つまり、どこかのケーブルにプラグインする）を持っている（たとえば、 、ホームゲートウェイ、ルータ、ファイアウォール、アクセスポイント、など）。いくつかのケースでは、ケーブルモデムの機能、すなわち、インターネットにアクセスする能力は、ホームゲートウェイ装置または内蔵マルチメディアターミナルアダプタ（eMTAで）に一体化されています。接続したら、ケーブルモデムは、HSIネットワークと最終的にはより広範なインターネットへの顧客をリンクします。
A piece of hardware located in a cable operator's local network (generally in a "headend", Section 3.10) that acts as the gateway to the Internet for cable modems in a particular geographic area. A simple way to think of the CMTS is as a router with interfaces on one side leading to the Internet and interfaces on the other connecting to Optical Nodes and then customers, in a so-called "last mile" network.
特定の地理的エリア内のケーブルモデムのためのインターネットへのゲートウェイとして機能する（一般に「ヘッドエンド」で、3.10）ケーブルオペレータのローカルネットワークに位置するハードウェアの一部。 CMTSを考えるための簡単な方法は、いわゆる「ラストマイル」ネットワークで、光ノードた後、顧客に接続する他のインターネットにつながる一方の側のインタフェースやインタフェースを持つルータとしてあります。
Also referred to simply as a "port". A port is a physical interface on a device used to connect cables in order to connect with other devices for transferring information/data. An example of a physical port is a CMTS port. A CMTS has both upstream and downstream network interfaces to serve the local access network, which are referred to as upstream or downstream ports. A port generally serves a neighborhood of hundreds of homes. Over time, CMTS ports tend to serve fewer and fewer homes, as the network is segmented for capacity growth purposes. Prior to DOCSIS version 3, a single CMTS physical port was used for either transmitting or receiving data downstream or upstream to a given neighborhood. With DOCSIS version 3, and the channel bonding feature, multiple CMTS physical ports can be combined to create a virtual port. A CMTS is also briefly defined in Section 2.6 of [RFC3083].
また、単に「ポート」と呼ばれます。ポートは、情報/データを転送するための他のデバイスと接続するためにケーブルを接続するために使用されるデバイス上の物理インタフェースです。物理ポートの例は、CMTSポートです。 CMTSは、アップストリームまたはダウンストリームポートと呼ばれるローカル・アクセス・ネットワークを配信する上流および下流の両方のネットワークインタフェースを有します。ポートは、一般家庭の何百もの近所を提供しています。時間が経つにつれて、CMTSポートは、ネットワークが、容量の成長のためにセグメント化されたとして、ますます少なく家にサービスを提供する傾向があります。 DOCSISバージョン3の前に、単一CMTSの物理ポートは、送信または所定の近傍の下流または上流のデータを受信するいずれかのために使用しました。 DOCSISバージョン3、およびチャネルボンディング機能と、複数のCMTSの物理ポートが仮想ポートを作成するために組み合わせることができます。 CMTSはまた、簡単に[RFC3083]のセクション2.6で定義されています。
A technique for combining multiple downstream and/or upstream channels to increase customers' download and/or upload speeds, respectively. Multiple channels from the Hybrid Fiber Coax (HFC) network (Section 3.11) can be bonded into a single virtual port (called a bonded group), which acts as a large single channel or port to provide increased speeds for customers. Channel bonding is a feature of Data Over Cable Service Interface Specification (DOCSIS) version 3, as described in [DOCSIS_MULPI].
それぞれ、顧客のダウンロードを増加および/または速度をアップロードするために、複数の下流および/または上流のチャネルを結合するための技術。ハイブリッドファイバ同軸（HFC）ネットワーク（セクション3.11）からの複数のチャネルは、顧客のために増加した速度を提供するために、大規模な単一のチャネルまたはポートとして作用する（結合する基と呼ばれる）単一の仮想ポートに結合することができます。 [DOCSIS_MULPI]で説明したように、チャネルボンディングは、データオーバーケーブルサービスインターフェース仕様（DOCSIS）バージョン3の機能です。
A type of cable used by a cable operator to connect customer premise equipment (CPE) -- such as TVs, cable modems (including eMTAs), and Set Top Boxes -- to the HFC network. This cable may be used within the home as well as in segments of the "last mile" network running to a home or customer premise location. There are many grades of coaxial cable that are used for different purposes. Different types of coaxial cable are used for different purposes on the network.
HFCネットワークに - そのようなテレビ、（eMTAs含む）、ケーブルモデム、セットトップボックスなど - 顧客宅内機器（CPE）を接続するケーブルオペレータによって使用されるケーブルのタイプ。このケーブルは、家庭内だけでなく、家庭や顧客構内の場所に実行されている「ラストマイル」ネットワークのセグメントで使用することができます。異なる目的のために使用されている同軸ケーブルの多くのグレードがあります。同軸ケーブルの異なるタイプのネットワーク上の別の目的のために使用されています。
A service/product offered by Comcast for delivering Internet service over a broadband connection.
ブロードバンド接続を介してインターネットサービスを提供するためのコムキャストが提供するサービス/製品。
Any device that resides at the customer's residence, connected to the Comcast network, whether controlled by Comcast or not.
顧客の居住地に存在する任意のデバイス、コムキャストによって制御されるかどうかにかかわらず、Comcastのネットワークに接続されています。
A reference standard developed by CableLabs that specifies how components on cable networks need to be built to enable HSI service over an HFC network, as noted in [DOCSIS_CM2CPE], [DOCSIS_PHY], [DOCSIS_MULPI], [DOCSIS_SEC], and [DOCSIS_OSSI]. These standards define the specifications for the cable modem and the CMTS such that any DOCSIS-certified cable modem will work on any DOCSIS-certified CMTS, independent of the selected vendor. The interoperability of cable modems and CMTSs allows customers to purchase a DOCSIS-certified modem from a retail outlet and use it on their cable-networked home. All DOCSIS-related standards are available to the public at the CableLabs website, at http://www.cablelabs.com.
参照[DOCSIS_CM2CPE]に記載されているように、ケーブルネットワーク上のコンポーネントは、HFCネットワーク上HSIサービスを可能にするために構築する必要がある方法を指定のCableLabsによって開発された標準、[DOCSIS_PHY]、[DOCSIS_MULPI]、[DOCSIS_SEC]、および[DOCSIS_OSSI]。これらの規格は、ケーブルモデムの仕様と任意のDOCSIS認定ケーブルモデムが選択されたベンダーとは無関係に、任意のDOCSIS認定CMTS上で動作するようCMTSを定義します。ケーブルモデムとCMTSはの相互運用性は、顧客が小売店からのDOCSIS認定モデムを購入し、そのケーブルネットワーク化自宅でそれを使用することができます。すべてのDOCSIS関連の標準はhttp://www.cablelabs.comで、CableLabsのウェブサイトで一般に公開されています。
Description of the direction in which a signal travels, in this case from the network to a user. Downstream traffic occurs when users are downloading something from the Internet, such as watching a web-based video, reading web pages, or downloading software updates.
信号はユーザへのネットワークから、この場合には、進行方向の説明。ユーザーは、このような、Webベースのビデオを見ているWebページを読み込む、またはソフトウェアアップデートをダウンロードするよう、インターネットから何かをダウンロードしているとき、ダウンストリームトラフィックが発生します。
A cable facility responsible for receiving TV signals for distribution over the HFC network to the end customers. This facility typically also houses one or more CMTSs. This is sometimes also called a "hub".
最終顧客へのHFCネットワーク上での配信のためのテレビ信号を受信するための責任ケーブル施設。この機能は、通常、1つ以上ののCMTSを収容します。これは、時々、「ハブ」と呼ばれています。
A network architecture used primarily by cable companies, comprised of fiber-optic and coaxial cables that currently deliver Voice, Video, and Internet services to customers, as defined in Section 1.2 of [DOCSIS_MULPI].
[DOCSIS_MULPI]のセクション1.2で定義されるように、現在の顧客に音声、ビデオ、およびインターネットサービスを提供する光ファイバーと同軸ケーブルで構成される主にケーブル会社によって使用されるネットワークアーキテクチャ、。
Standardized technology for monitoring and/or recording subscribers' upstream and downstream Internet usage data based on their cable modem. The data is collected from the CMTS and sent to a server for further processing. Additional information is available at http://www.ipdr.org, as well as [IPDR_Standard] and [DOCSIS_IPDR].
そのケーブルモデムに基づいて監視および/または加入者の上流と下流のインターネット利用状況データを記録するための標準化された技術。データがCMTSから収集し、さらなる処理のためにサーバに送信されます。追加情報は[IPDR_Standard]ならびに、http://www.ipdr.orgで利用可能で、[DOCSIS_IPDR]。
A component of the HFC network generally located in customers' local neighborhoods that is used to convert the optical signals sent over fiber-optic cables to electrical signals that can be sent over coaxial cable to customers' cable modems, or vice versa. A fiber-optic cable connects the Optical Node, through distribution hubs, to the CMTS, and coaxial cable connects the Optical Node to customers' cable modems.
一般に、ケーブルモデム、またはその逆の顧客の顧客に、同軸ケーブルを介して送信することができる電気信号に光ファイバケーブルを介して送信される光信号を変換するために使用される局所近傍の内に位置HFCネットワークのコンポーネント。光ファイバケーブルは、CMTSに、物流ハブを通じて、光ノードを接続し、同軸ケーブルは、顧客のケーブルモデムに光ノードを接続しています。
The peak speed associated with a tier of service purchased by a customer. For example, a customer with a 105 Mbps downstream and 10 Mbps upstream speed tier would be said to be provisioned with 105 Mbps of downstream bandwidth and 10 Mbps of upstream bandwidth. This is often referred to as 105/10 service in industry parlance.
顧客が購入したサービスの層に関連付けられたピークスピード。例えば、下流の105 Mbpsおよび10 Mbpsの上流の速度段を有する顧客は、ダウンストリーム帯域幅の105 Mbpsおよびアップストリーム帯域幅の10 Mbpsのでプロビジョニングされると言われるであろう。これは、多くの場合、業界用語で10分の105サービスと呼ばれています。
The Provisioned Bandwidth is the speed that a customer's modem is configured (and the network is engineered) to deliver on a regular basis (which is not the same as a "Committed Information Rate" or a guaranteed rate). Internet speeds are generally a best effort service that are dependent on a number of variables, many of which are outside the control of an Internet Service Provider (ISP). In general, speeds do not typically exceed a customer's provisioned speed. Comcast, however, invented a technology called "PowerBoost" [PowerBoost_Specification] that, for example, enables users to experience brief boosts above their provisioned speeds while they transfer large files over the Internet, by utilizing excess capacity that may be available in the network at that time.
提供される帯域幅は、顧客のモデムが（「認定情報レート」または保証速度と同じではありません）、定期的に配信するように構成された（そしてネットワークが設計された）の速度です。インターネットの速度は、一般的にインターネットサービスプロバイダ（ISP）のコントロール外にあるその多くの変数の数に依存するベストエフォート型のサービスです。一般的に、速度は一般的に、顧客のプロビジョニングの速度を超えないようにしてください。 Comcastは、しかし、例えば、彼らはインターネット上で大きなファイルを転送している間にネットワークで利用できる余剰能力を利用することによって、彼らのプロビジョニング速度以上の簡単なブーストを体験することができます、という「PowerBoost」と呼ばれる技術[PowerBoost_Specification]を発明しましたその時。
A set of techniques to manage network resources to ensure a level of performance to specific data flows, as described in [RFC1633] and [RFC2475]. One method for providing QoS to a network is by differentiating the type of traffic by class or flow and assigning priorities to each type. When the network becomes congested, the data packets that are marked as having higher priority will have higher likelihood of being serviced.
[RFC1633]及び[RFC2475]に記載されているように、特定のデータへの性能のレベルを保証するために、ネットワークリソースを管理するための技術のセットが、流れます。ネットワークにQoSを提供するための一つの方法は、クラスまたはフローによってトラフィックの種類を区別し、各タイプに優先順位を割り当てることです。ネットワークが混雑になると、高い優先度を持つものとしてマークされたデータパケットは、サービス中のより高い可能性を持つことになります。
Description of the direction in which a signal travels, in this case from the user to the network. Upstream traffic occurs when users are uploading something to the network, such as sending email, sending files to another computer, or uploading photos to a digital photo website.
信号は、ネットワークへのユーザから、この場合には、進行方向の説明。アップストリームトラフィックは、ユーザーが、このような、電子メールを送信して別のコンピュータにファイルを送信、またはデジタル写真のウェブサイトに写真をアップロードすると、ネットワークに何かをアップロードするときに発生します。
Comcast began the engineering project to develop a new congestion management system in March 2008, the same month that Comcast hosted the 71st meeting of the IETF in Philadelphia, PA, USA. On May 28, 2008, Comcast participated in an IETF Peer-to-Peer Infrastructure Workshop [RFC5594], hosted by the Massachusetts Institute of Technology (MIT) in Cambridge, MA, USA.
Comcastはコムキャストは、フィラデルフィア、PA、USAでのIETFの第71回会合を開催したことを同じ月、2008年3月に新たな輻輳管理システムを開発するためのエンジニアリングプロジェクトを開始しました。 2008年5月28日には、Comcastは、マサチューセッツ州ケンブリッジ、米国のマサチューセッツ工科大学（MIT）が主催IETFピアツーピアインフラワークショップ[RFC5594]に参加しました。
In order to participate in this workshop, interested attendees were asked to submit a paper to a technical review team, which Comcast did on May 9, 2008, in [COMCAST_P2PI_PAPER]. Comcast subsequently attended and participated in this valuable workshop. During the workshop, Comcast outlined the high-level design for a new congestion management system [COMCAST_P2PI_PRES] and solicited comments and other feedback from attendees and other members of the Internet community (presentations were also posted to the IETF's P2Pi mailing list). The congestion management system outlined in that May 2008 workshop was later tested in trial markets and is in essence what was then deployed by Comcast later in 2008.
このワークショップに参加するためには、興味を持って参加者は、[COMCAST_P2PI_PAPER]で、コムキャストは、2008年5月9日に行った技術審査チーム、に用紙を提出するように求めていました。 Comcastはその後に出席し、この貴重なワークショップに参加しました。ワークショップで、Comcastは[COMCAST_P2PI_PRES]新しい輻輳管理システムのための高レベルの設計を概説し、参加者とインターネットコミュニティの他のメンバー（プレゼンテーションもIETFのP2Piメーリングリストに投稿された）からのコメントやその他のフィードバックを募集しました。その2008年5月のワークショップで概説した輻輳管理システムは、後に裁判市場でテストされ、その後2008年にコムキャストによって展開されたものの本質であるました。
Following an August 2008 FCC document [FCC_Memo_Opinion] regarding how Comcast managed congestion on its High-Speed Internet ("HSI") network, Comcast disclosed to the FCC [FCC_Net_Mgmt_Response] and the public additional technical details of the congestion management system that it intended to and did implement by the end of 2008 [FCC_Congest_Mgmt_Ltr], including the thresholds involved in this new
[FCC_Memo_Opinion]コムキャストは、その高速インターネット（「HSI」）ネットワークの輻輳を管理する方法については2008年8月FCCの文書に続き、ComcastはFCC [FCC_Net_Mgmt_Response]とそれが意図した輻輳管理システムの公共の追加技術的な詳細に開示されそして、この新しいに関与したしきい値を含む、[FCC_Congest_Mgmt_Ltr] 2008年末までに実施しました
system. While the description of how this system is deployed in the Comcast network is necessarily specific to the various technologies and designs specific to that network, a similar system could be deployed on virtually any large-scale ISP network or other IP network.
システム。このシステムは、Comcastのネットワークに展開する方法の説明は、様々な技術に必ずしも特異的であり、そのネットワークに特定の設計が、同様のシステムは、実質的に任意の大規模なISPのネットワークまたは他のIPネットワーク上で展開することができます。
Comcast's HSI network has elements that are shared across many subscribers. This means that Comcast's HSI customers share upstream and downstream bandwidth with their neighbors. Although the available bandwidth is substantial, so, too, is the demand. Thus, when a relatively small number of customers in a neighborhood place disproportionate demands on network resources, this can cause congestion that degrades their neighbors' Internet experience. The goal of Comcast's new congestion management system is to enable all users of our network resources to access a "fair share" of that bandwidth, in the interest of ensuring a high-quality online experience for all of Comcast's HSI customers.
ComcastのHSIネットワークは、多くの加入者間で共有されている要素を持っています。これは、ComcastのHSIの顧客は彼らの隣人と上流と下流の帯域幅を共有することを意味します。利用可能な帯域幅がかなりありますが、そう、あまりにも、需要があります。このように、ネットワークリソース上の不均衡な需要近所の代わりに顧客の数が比較的少ない、これは彼らの隣人のインターネット体験を劣化させる渋滞を引き起こす可能性があります。 Comcastの新しい輻輳管理システムの目標は、ComcastのHSIの顧客のすべてのための高品質なオンライン体験を確保する金利で、その帯域幅の「公正なシェア」にアクセスするために、当社のネットワーク・リソースのすべてのユーザーを有効にすることです。
Importantly, the new approach is protocol-agnostic; that is, it does not manage congestion by focusing on the use of the specific protocols that place a disproportionate burden on network resources, or any other protocols. Rather, the new approach focuses on managing the traffic of those individuals who are using the most bandwidth at times when network congestion threatens to degrade subscribers' broadband experience and who are contributing disproportionately to such congestion at those points in time.
重要なのは、新しいアプローチは、プロトコルに依存しないです。つまり、それは、ネットワークリソース、または任意の他のプロトコルに不均衡な負担をかけ、特定のプロトコルの使用に焦点を当てることによって輻輳を管理しません。むしろ、新しいアプローチでは、ネットワークの輻輳が加入者のブロードバンド体験を低下させると脅すときの回で最も帯域幅を使用していて、時間内にそれらの点で、このような混雑に不相応に貢献している人たちの個人のトラフィックを管理に焦点を当てています。
Specific details about these practices, including relevant threshold information, the type of equipment used, and other particulars, are discussed at some length later in this document. At the outset, however, we present a very high-level, simplified overview of how these practices work. Despite all the detail provided further below, the fundamentals of this approach can be summarized succinctly:
関連する閾値情報を含むこれらのプラクティス、使用される機器の種類、およびその他の細目についての具体的な詳細は、このドキュメントのいくつかの長さで議論されています。最初に、しかし、我々は非常に高いレベルの、これらのプラクティスがどのように機能するかの単純化した概要を提示します。さらに以下に提供されるすべてのディテールにもかかわらず、このアプローチの基礎を簡潔に要約することができます。
1. Software installed in the Comcast network continuously examines aggregate traffic usage data for individual segments of Comcast's HSI network. If overall upstream or downstream usage on a particular segment of Comcast's HSI network reaches a pre-determined level, the software moves on to step two.
Comcastのネットワークにインストール1.ソフトウェアは、継続的にComcastのHSIネットワークの個々のセグメントの集約トラフィックの使用状況データを調べます。 ComcastのHSIネットワークの特定のセグメント上の全体的な上流または下流の使用量が所定のレベルに達した場合、ソフトウェアは、二つのステップに進みます。
2. At step two, the software examines bandwidth usage data for subscribers in the affected network segment to determine which subscribers are using a disproportionate share of the bandwidth.
2.ステップ2では、ソフトウェアは、加入者が帯域幅の不均衡な配分を使用して決定するために、影響を受けるネットワークセグメント内の加入者のための帯域幅使用量データを調べます。
If the software determines that a particular subscriber or subscribers have been the source of high volumes of network traffic during a recent period of minutes, traffic originating from that subscriber or those subscribers temporarily will be assigned a lower priority status.
ソフトウェアは、特定の加入者または加入者はトラフィックがその加入者から発信またはそれらの加入者が一時的に優先度の低いステータスが割り当てられます、数分の最近の期間中に大量のネットワークトラフィックの送信元となっていると判断した場合。
3. During the time that a subscriber's traffic is assigned the lower priority status, their packets will not be delayed or dropped so long as the network segment is not actually congested. If, however, the network segment becomes congested, their packets could be intermittently delayed or dropped.
3.加入者のトラフィックを優先度の低いステータスが割り当てられている時間の間に、それらのパケットが遅延または限りネットワークセグメントは、実際に輻輳していないとして廃棄されることはありません。しかし、ネットワークセグメントが混雑した場合、そのパケットが断続的に遅延したりドロップすることができます。
4. The subscriber's traffic returns to normal priority status once his or her bandwidth usage drops below a set threshold over a particular time interval.
彼または彼女の帯域幅の使用量は、特定の時間間隔で、設定されたしきい値を下回ったら4.加入者のトラフィックは通常の優先度の状態に戻ります。
Comcast undertook considerable effort, over the course of many months, to formulate our plans for this congestion management approach, adjusting them, and subjecting them to real-world trials. Market trials were conducted in Chambersburg, PA; Warrenton, VA; Lake City, FL; East Orange, FL; and Colorado Springs, CO, between June and September 2008. This enabled us to validate the utility of the general approach and collect substantial trial data to test multiple variations and alternative formulations.
Comcastはそれらを調整し、実世界の臨床試験にそれらをさらす、この輻輳管理アプローチのために我々の計画を策定するために、何ヶ月にわたって、かなりの努力を行いました。市場の試験はペンシルバニア州で行われました。ウォレントン、VA;レイクシティ、フロリダ州。イーストオレンジ、FL; 6月と2008年9月の間にコロラドスプリングス、COは、これが一般的なアプローチの有用性を検証し、複数のバリエーションおよび代替処方をテストするために、かなりの試験データを収集することができました。
Many people have questioned whether congestion should ever exist at all, if an ISP was adding sufficient capacity. There is certainly a relationship between capacity and congestion. But there are two types of congestion that generally present themselves in a network.
多くの人々は、ISPは、十分な容量を追加された場合は混雑が今まで、まったく存在するかどうかを疑問視しています。容量と輻輳の関係は確かにあります。しかし、一般的にネットワークで自分自身を提示し、混雑の2種類があります。
The first general type of congestion is regularly occurring and is the result of gradually increasing traffic levels up to a point where typical usage peaks cause congestion on a regular basis. Comcast, like many ISPs, has a set capacity management process by which capacity additions are automatically triggered based on certain usage trends; this process is geared towards bringing additional capacity to the network prior to the onset of regularly occurring congestion. As such, capacity is added when needed and before it presents noticeable effects. This process is in place since capacity additions are not instantaneous and in many cases require significant physical work.
渋滞の最初の一般的なタイプは、定期的に発生し、徐々に一般的な使用のピークは定期的に渋滞を起こす時点までのトラフィックレベルを上昇させる結果となっています。 Comcastは、多くのISPと同様に、容量の追加を自動的に特定の使用傾向に基づいてトリガされるセット容量管理プロセスを有しています。このプロセスは、定期的に輻輳を発生開始する前にネットワークに追加容量をもたらすを目指しています。そのため、必要なときに容量が追加され、それが顕著な効果を提示する前に。容量の追加は瞬時ではなく、多くの場合、重要な物理的な作業を必要とするため、このプロセスが整備されています。
The second general type of congestion is unpredictable congestion, which can occur for a wide range of reasons. One example may be due to current events, where users may be all rushing to access specific content at the exact same time, and where the systems serving that content may not be able to keep up with demand. Another example may be due to a localized disaster, where some network paths have been destroyed or otherwise impaired, and where many users are attempting to communicate with one another at traffic levels significantly above normal.
輻輳の第二の一般的なタイプは、理由の広い範囲で発生する可能性が予測できない渋滞です。一つの例は、ユーザーがすべて正確に同じ時間に特定のコンテンツにアクセスするために急いで、そのコンテンツを提供するシステムが需要に追いつくことができない場合がありすることができる現在のイベント、に起因する可能性があります。別の例では、何らかのネットワーク経路が破壊または他の方法で損なわれているローカライズされた災害にあってもよく、ここで、多くのユーザーが大幅に正常上記トラフィックレベルで互いに通信しようとしています。
Thus, in both cases, even with continuous upgrades and constant investment in additional capacity, the fact remains that network capacity is not unlimited. A congestion management system, absent superior protocol-based solutions that do not currently exist, can therefore help manage the effects of congestion on users, improving their Internet experience.
したがって、どちらの場合にも継続的なアップグレードと追加の容量が一定の投資で、実際には、ネットワーク容量は無制限ではないことに変わりはありません。輻輳管理システム、現在存在していない不在の優れたプロトコルベースのソリューションは、したがって、彼らのインターネット体験を向上させること、ユーザの渋滞の影響を管理しやすくすることができます。
It is important to note that the implementation details below and the overall design of the system are matched to traffic patterns that exist on the Internet today and that the authors believe will exist in the near future. While the authors desired to make the system highly adaptable and a good long-term network investment, significant changes in such traffic patterns may necessitate a change in the configuration of the system or, in extreme cases, a different type of system altogether.
以下の実装の詳細とシステム全体の設計は今日、インターネット上に存在するトラフィックパターンにマッチしていること、および著者が近い将来に存在すると考えていることに注意することが重要です。著者らは、システムが適応性の高いと良好な長期のネットワークへの投資することが望まが、このようなトラフィックパターンに大きな変化は、システムまたは完全にシステムの、極端な場合には、異なる種類の構成の変更を必要とするかもしれません。
To understand exactly how these new congestion management practices work, it is helpful to have a general understanding of how Comcast's HSI network is designed. Comcast's HSI network is what is commonly referred to as a hybrid fiber-coax network, with coaxial cable connecting each subscriber's cable modem to an Optical Node, and fiber-optic cables connecting the Optical Node, through distribution hubs, to the Cable Modem Termination System (CMTS), which is also known as a "data node". The CMTSs are then connected to higher-level routers, which in turn are connected to Comcast's Internet backbone facilities. Today, Comcast has over 3,200 CMTSs deployed throughout our network, serving over 15 million HSI subscribers.
これらの新しい輻輳管理の実践が働く方法を正確に理解するには、ComcastのHSIネットワークが設計された方法の一般的な理解を持っていると便利です。 ComcastのHSIネットワークは、一般に光ノードを各加入者のケーブルモデムを接続する同軸ケーブル、光ノードを接続する光ファイバケーブルと、分配ハブを介して、ケーブルモデム終端システムに、ハイブリッドファイバ同軸ネットワークと呼ばれるものですまた、「データノード」として知られている（CMTS）。 CMTSはその後、今度はComcastのインターネットバックボーン施設に接続されている、より高いレベルのルーターに接続されています。今日、Comcastは15万人以上のHSIの加入者にサービスを提供する、当社のネットワーク全体に展開3,200以上のCMTSを持っています。
Each CMTS has multiple "ports" that handle traffic coming into and leaving the CMTS. In particular, each cable modem deployed on the Comcast HSI network is connected to the CMTS through the ports on the CMTS. These ports can be either "downstream" ports or "upstream" ports, depending on whether they send information to cable modems (downstream) or receive information from cable modems (upstream) attached to the port. (Note that the term "port" as used here generally contemplates single channels on a CMTS, but these statements will apply to virtual channels, also known as "bonded groups", in a DOCSIS 3.0 environment.) Even without channel bonding, multiple channels are usually configured to come out of each physical port. Said another way, there is generally a mapping of multiple channels to each physical port.
各CMTSは、トラフィックが入ってくるとCMTSを残して扱う複数の「ポート」を持っています。具体的には、ComcastのHSIネットワーク上に展開各ケーブルモデムは、CMTS上のポートを介してCMTSに接続されています。これらのポートは、それらがケーブルモデム（下流）に情報を送信したり、ポートに接続されたケーブルモデム（上流）から情報を受信するかどうかに応じて、「下流」ポートまたは「上流」ポートのいずれかとすることができます。 （一般的に、ここで使用される用語「ポート」は、CMTS上の単一チャンネルを企図していることに注意してください、これらのステートメントは、DOCSIS 3.0環境で、また、「結合基」として知られている仮想チャネルに適用されます。）でも、チャネルボンディング、複数のチャネルなし通常、各物理ポートから出てくるように設定されています。別の方法は、一般に、各物理ポートに複数のチャネルのマッピングがあると述べました。
Currently, on average, approximately 275 cable modems share the same downstream port, and about 100 cable modems share the same upstream port; however, this is constantly changing (both numbers generally become smaller over time, based on current DOCSIS technology). Both types of ports can experience congestion that could degrade the broadband experience of our subscribers and, unlike with the previous congestion management practices, both upstream and downstream traffic are subject to management in this new congestion management system.
現在、平均して、約275ケーブルモデムは、同じダウンストリームポートを共有し、そして約100ケーブルモデムは同一のアップストリームポートを共有します。しかし、これは常に（両方の数は、一般的に、現在のDOCSISテクノロジーに基づいて、時間の経過とともに小さくなって）変化しています。ポートの両方のタイプは、前の輻輳管理の実践とは異なり、当社の加入者のブロードバンド体験を劣化させる可能性が渋滞を体験することができ、両方の上流と下流のトラフィックは、この新しい輻輳管理システムにおける管理の対象となっています。
Based upon the design of the network and traffic patterns observed, the most likely place for congestion to occur is on these CMTS ports. As a result, the congestion management system measures the traffic conditions of CMTS ports, and applies any policy actions to traffic on those ports (rather than some other, more distant segment of the network).
観測ネットワークの設計やトラフィックパターンに基づいて、輻輳が発生する可能性が最も高い場所は、これらのCMTSポートです。その結果、輻輳管理システムは、CMTSポートのトラフィック状態を測定し、これらのポート（よりむしろネットワークのいくつかの他の、より遠いセグメント）上のトラフィックに任意のポリシー・アクションを適用します。
To implement Comcast's new protocol-agnostic congestion management practices, Comcast purchased new hardware and software that were deployed near the Regional Network Routers ("RNRs") that are further upstream in Comcast's network. This new hardware consists of Internet Protocol Detail Record ("IPDR") servers, Congestion Management servers, and PacketCable Multimedia ("PCMM") servers. Further details about each of these pieces of equipment can be found below, in Section 7.4. It is important to note here, however, that even though the physical location of these servers is at the RNR, the servers communicate with -- and manage individually -- multiple ports on multiple CMTSs to effectuate the practices described in this document. That is to say, bandwidth usage on one CMTS port will have no effect on whether the congestion management practices described herein are applied to a subscriber on a different CMTS port.
Comcastの新しいプロトコルに依存しない輻輳管理の実践を実装するには、ComcastはComcastのネットワークで、さらに上流にある地域ネットワークルータ（「RNRs」）の近くに配備された新しいハードウェアやソフトウェアを購入しました。この新しいハードウェアは、インターネットプロトコルの詳細レコード（「IPDR」）サーバ、輻輳管理サーバ、およびPacketCableのマルチメディア（「PCMM」）のサーバーで構成されています。装置のこれらの部分の各々についてのさらなる詳細は、セクション7.4で、以下見出すことができます。個別に管理する - - 複数のポートを複数のCMTS上で、この文書で説明するプラクティスを実現するためには、これらのサーバの物理的な場所はRNRであるにも関わらず、サーバと通信することを、しかし、ここで注意することが重要です。つまり、あるCMTSポートの帯域幅の使用は、本明細書に記載の輻輳管理慣行が異なるCMTSポート上の加入者に適用されるかどうかには影響がありません、と言うことです。
Figure 1 provides a simplified graphical depiction of the network architecture just described:
図1は、ちょうど説明したネットワークアーキテクチャの簡略化されたグラフィカルな描写を提供します。
Figure 1: Simplified Network Diagram Showing High-Level Comcast
図1：簡体ネットワークダイアグラムは、高レベルのコムキャストを表示
Network and Servers Relevant to Congestion Management
ネットワークと輻輳管理に関連するサーバー
-------------------------
/ \
| Comcast Internet Backbone |
\ -----
+------------+ --------------------/ \
| Congestion | / \
| Management |<+++GigE++++ +---->| Internet |
| Server | + | | Backbone |
+------------+ + | \ Router /
+ Fiber \ /
+------------+ + | -----
| QoS | + |
| Server |<+++GigE++++ \/
| | + -----
+------------+ + / \
+ / \
+------------+ + | Regional |
| Statistics | +++++++>| Network |
| Collection |<+++GigE++++ | Router |
| Server | \ /
+------------+ +---Fiber------>\ /<------Fiber----+
| ----- |
\/ \/
----- -----
/ \ / \
/ Local \ / Local \
| Market | | Market |
\ Router / \ Router /
+--------->\ /<------------+ \ /
| ----- | ------
| /\ | /\
Fiber | Fiber |
| Fiber | Fiber
| | | |
\/ \/ \/ \/
/------\ /------\ /------\ /------\
| CMTS | | CMTS | | CMTS | | CMTS |
\------/ \------/ \------/ \------/
/\ /\ /\ /\
| | | |
Fiber Fiber Fiber Fiber
| | | |
\/ \/ \/ \/
+---------+ +---------+ +---------+ +---------+
| Optical | | Optical | | Optical | | Optical |
| Node | | Node | | Node | | Node |
+---------+ +---------+ +---------+ +---------+
/\ /\ /\ /\ /\ /\
|| || ||______ || _____|| ||
Coax Coax |__Coax| Coax |Coax__| Coax
|| || || || || ||
\/ \/ \/ \/ \/ \/
+=======+ +=======+ +=======+ +=======+ +=======+ +=======+
= Cable = = Cable = = Cable = = Cable = = Cable = = Cable =
= Modem = = Modem = = Modem = = Modem = = Modem = = Modem =
+=======+ +=======+ +=======+ +=======+ +=======+ +=======+
================================================================
+ Note: This diagram is a simplification of the actual network +
+ and servers, which in actuality includes significant +
+ redundancy and other details too complex to represent here. +
================================================================
Figure 1
図1
Each Comcast HSI subscriber's cable modem has a "bootfile", which is essentially a configuration file that contains certain pieces of information about the subscriber's service to ensure that the service functions properly. (Note: No personal information is included in the bootfile; it only includes information about the service that the subscriber has purchased.) For example, the bootfile contains information about the maximum speed (what we refer to in this document as the "provisioned bandwidth") that a particular modem can achieve based on the tier (personal/residential, commercial, etc.) the customer has purchased. Bootfiles are generally reset from time to time to account for changes in the network and other updates, and this is usually done through a command sent from the network and without the subscriber noticing. In preparation for the transition to this new congestion management system, Comcast sent new bootfiles to our HSI customers' cable modems that created two Quality of Service (QoS) levels for Internet traffic going to and from the cable modem: (1) "Priority Best Effort" ("PBE") traffic; and (2) "Best Effort" ("BE") traffic. As with previous changes to cable modem bootfiles, the replacement of the old bootfile with the new bootfile requires no active participation by Comcast customers.
各ComcastのHSIの加入者のケーブルモデムは、本質的にそのサービスが正しく機能することを確認するために、加入者のサービスに関する特定の情報が含まれている設定ファイルである「ブートファイル」を、持っています。 （注：個人情報は、ブートファイルに含まれていない、それだけで、加入者が購入したサービスに関する情報が含まれます）たとえば、ブートファイルは、最高速度に関する情報が含まれています（私たちは、「プロビジョニング帯域幅として、この文書で何を参照してください「）は、特定のモデムは、顧客が購入したティア（など、商業用、住宅用/個人）に基づいて実現できること。 Bootfilesは、一般的に時間からネットワークやその他の更新の変化を考慮するための時間にリセットされ、これは、通常、ネットワークから加入者気付かずに送信されたコマンドを介して行われます。この新しい輻輳管理システムへの移行のための準備では、Comcastは（QoS）のサービスの2つの品質を作成し、当社のHSIの顧客のケーブルモデムに新しいbootfilesを送ったケーブルモデムにしてから行くのインターネットトラフィックのレベル：（1）「優先ベストエフォート」（ 『PBE』）トラフィック。 （2） "ベストエフォート" トラフィック（ "BE"）。ケーブルモデムbootfilesに前の変更と同じように、新しいブートファイルと古いブートファイルの交換は、Comcastの顧客によって何の積極的な参加を必要としません。
Thereafter, all traffic going to or coming from cable modems on the Comcast HSI network is designated as either PBE or BE. PBE is the default status for all Internet traffic coming from or going to a particular cable modem. Traffic is designated BE for a particular cable modem only when both of two conditions are met: o First, the usage level of a particular upstream or downstream port of a CMTS, as measured over a particular period of time, must be nearing the point where congestion could degrade users' experience. We refer to this as the "Near Congestion State" and, based on the technical trials we have conducted (further validated in our full deployment), we have established a threshold, described in more detail below, for when a particular CMTS port enters that state.
その後、すべてのトラフィックに行くか、ComcastのHSIネットワーク上のケーブルモデムから来るのいずれかPBEとして指定またはBEされます。 PBEは、すべてのインターネットトラフィックから来たり、特定のケーブルモデムに行くのデフォルトの状態です。まず、CMTSの特定の上流または下流ポートの使用レベルは、特定の期間にわたって測定され、ここでポイントに近づいされなければならない○：トラフィックは2つの条件の両方が満たされる場合にのみ、特定のケーブルモデムとすることが指定されています渋滞は、ユーザーの経験を劣化させることができます。特定のCMTSポートがあることに入ったとき、私たちは「近く輻輳状態」としてこれを参照して、我々が行ってきた技術的な試験に基づいて、（さらに、当社の完全な展開で検証）、我々は以下でより詳細に説明するしきい値を、確立している、のために状態。
o Second, a particular subscriber must be making an extended, high contribution to the bandwidth usage on the particular port, relative to the service tier they purchased, as measured over a particular period of time. We refer to this as the "Extended High Consumption State" and, based on the technical trials we have conducted (further validated in our full deployment), we have established a threshold, described in more detail below, for when a particular user enters that state.
時間の特定の期間にわたって測定されたO第二に、特定の加入者は、彼らが購入したサービス層に対する特定のポート上の帯域幅の使用に拡張された、高い貢献をしなければなりません。我々は、我々が行ってきた技術的な臨床試験（さらに、当社の完全な展開で検証）、我々は特定のユーザーがいることを入ったときのために、以下に詳細に説明、しきい値を確立しているに基づいて「拡張高い消費状態」と、としてこれを参照します状態。
When, and only when, both conditions are met, a user's upstream or downstream traffic (depending on which type of port is in the Near Congestion State) is designated as BE. Then, to the extent that actual congestion occurs, any delay resulting from the congestion will affect BE traffic before it affects PBE traffic.
両方の条件が満たされた場合にのみ、ユーザのアップストリームまたはダウンストリームトラフィック（ポートのタイプは近く輻輳状態であるかに応じて）場合、およびBEとして指定されます。それはPBEのトラフィックに影響を与える前に、次に、実際の輻輳が発生する程度に、渋滞に起因するいかなる遅延はBEトラフィックに影響を与えます。
We now explain the foregoing in greater detail in the following sections.
私たちは今、次のセクションで詳細に前述の説明します。
7.1. Thresholds for Determining When a CMTS Port Is in a Near Congestion State
7.1. CMTSポートの近く輻輳状態にあるときに決定するためのしきい値
For a CMTS port to enter the Near Congestion State, traffic flowing to or from that CMTS port must exceed a specified level (the "Port Utilization Threshold") for a specific period of time (the "Port Utilization Duration"). The Port Utilization Threshold on a CMTS port is measured as a percentage of the total aggregate upstream or downstream bandwidth for the particular port during the relevant timeframe. The Port Utilization Duration on the CMTS is measured in minutes.
近く輻輳状態を入力するCMTSポートの場合、またはそこから流れるトラフィックは、ポートが特定の期間（「ポートの使用状況期間」）に指定したレベル（「ポートの使用率のしきい値」）を超えなければならないCMTS。 CMTSポートのポート使用率のしきい値は、関連期間中に特定のポートの総計上流または下流の帯域幅のパーセンテージとして測定されます。 CMTS上のポートの使用時間は分単位で測定されます。
Values for each of the thresholds that are used as part of this congestion management technique have been tentatively established after an extensive process of lab tests, simulations, technical trials, vendor evaluations, customer feedback, and a third-party consulting analysis. In the same way that specific anti-spam or other network management practices are adjusted to address new issues that arise, it is a near certainty that these values will change over time, as Comcast gathers more data and performs additional analysis resulting from wide-scale use of the new technique. Moreover, as with any large network or software system, software bugs and/or unexpected errors may arise, requiring software patches or other corrective actions. As always, Comcast's decisions on these matters are driven by the marketplace imperative that we deliver the best possible experience to our HSI subscribers.
この輻輳管理技術の一部として使用されているしきい値のそれぞれの値は、暫定的にラボテスト、シミュレーション、技術的な試験では、ベンダーの評価、顧客からのフィードバック、およびサードパーティのコンサルティング解析の大規模な処理の後に確立されています。コムキャストは、より多くのデータを収集し、大規模に起因する追加的な分析を行うように、特定のアンチスパムまたは他のネットワーク管理手法を生じる新しい問題に対処するように調整されるのと同じ方法で、それは、これらの値が時間の経過とともに変化することがほぼ確実です新技術の使用。また、いずれかの大規模なネットワーク又はソフトウェアシステム、ソフトウェアのバグおよび/または予期しないエラーと同様にソフトウェアパッチまたは他の是正措置を必要とする、生じ得ます。いつものように、これらの事項についてComcastの決定は、我々のHSIの加入者に可能な限り最高の体験を提供する市場が不可欠で駆動されています。
Given our experience as described above, we determined that a starting point for the upstream Port Utilization Threshold should be 70 percent and the downstream Port Utilization Threshold should be 80 percent. For the Port Utilization Duration, we determined that the starting point should be approximately 15 minutes (although some technical limitations in some newer CMTSs deployed on Comcast's network may make this time period vary slightly). Thus, over any 15-minute period, if an average of more than 70 percent of a port's upstream bandwidth capacity or more than 80 percent of a port's downstream bandwidth capacity is utilized, that port is determined to be in a Near Congestion State.
前述したように、私たちの経験を考えると、我々は、上流ポート使用率のしきい値のための出発点は70％とダウンストリームポートの使用率しきい値が80％であるべきであることを決定しました。ポートの使用期間については、我々は出発点は、約15分（Comcastのネットワーク上に展開いくつかの新しいCMTSは中にいくつかの技術的な制限は、この期間がわずかに変化させるかもしれないが）であることを決定しました。ポートのアップストリーム帯域幅容量の70％以上、またはポートのダウンストリーム帯域幅容量の80％以上の平均値が利用される場合したがって、任意の15分の期間にわたって、そのポートの近く輻輳状態であると判定されました。
Based on the trials conducted and operational experience to date, a typical CMTS port on our HSI network is in a Near Congestion State only for relatively small portions of the day, if at all, though there is no way to forecast what will be the busiest time on a particular port on a particular day. Moreover, the trial data and operational experience indicate that, even when a particular port is in a Near Congestion State, the instances where the network actually becomes congested during the Port Utilization Duration are few, and managed users whose packets may be intermittently delayed or dropped during those congested periods perceive little, if any, effect, as discussed below.
忙しいがどうなるかを予測する方法はありませんけれどもこれまでの実施試験や運用経験に基づき、当社HSIネットワーク上の典型的なCMTSポートは、すべての場合、一日の比較的小さな部分に近く輻輳状態であります特定の日に特定のポート上の時間。また、試験データと運用経験は、特定のポートが近く輻輳状態にあるときでも、ネットワークが実際にポートの使用期間中に混雑のインスタンスがいくつかあり、そのパケットを断続的に遅れたり、落下することができるユーザを管理し、ことを示しています後述するように、それらの混雑期間中に、もしあれば、ほとんど効果を知覚します。
7.2. Thresholds for Determining When a User Is in an Extended High Consumption State and for Release from That Classification
7.2. ユーザーが拡張大量消費国で、その分類からリリースされたときのために決定するためのしきい値
Once a particular CMTS port is in a Near Congestion State, the software examines whether any cable modems are consuming bandwidth disproportionately. (Note: Although each cable modem is typically assigned to a particular household, the software does not and cannot actually identify individual users or the number of users sharing a cable modem, or analyze particular users' traffic.) For purposes of this document, we use "cable modem", "user", and "subscriber" interchangeably to mean a subscriber account or user account and not an individual person. For a user to enter an Extended High Consumption State, he or she must consume greater than a certain percentage of his or her provisioned upstream or downstream bandwidth (the "User Consumption Threshold") for a specific length of time (the "User Consumption Duration"). The User Consumption Threshold is measured as a user's consumption of a particular percentage of his or her total provisioned upstream or downstream bandwidth. That bandwidth is the maximum speed that a particular modem can achieve based on the tier (personal/residential, commercial, etc.) the customer has purchased. For example, if a user buys a service with speeds of 50 Mbps downstream and 10 Mbps upstream, then his or her provisioned downstream speed is 50 Mbps and provisioned upstream speed is 10 Mbps. It is also important to note that because the User Consumption Threshold is a percentage of provisioned bandwidth for a particular user account, and not a static value, users of higher-speed tiers have correspondingly higher User Consumption Thresholds. Lastly, the User Consumption Duration is measured in minutes.
特定のCMTSポートが近く輻輳状態になると、ソフトウェアは、任意のケーブルモデムは不釣り合いな帯域幅を消費しているかどうかを調べます。 （注：各ケーブルモデムは、典型的には、特定の世帯に割り当てられているが、ソフトウェアは、実際に個々のユーザーまたはケーブルモデムを共有するユーザーの数を特定し、または特定のユーザのトラフィックを分析することはできませんしません。）この文書の目的のために、私たちは加入者アカウントまたはユーザーアカウントではなく個人を意味するために互換「ケーブルモデム」、「ユーザー」、および「加入者」を使用。拡張高い消費状態を入力するようにユーザのために、彼または彼女は、時間の特定の長さ（「ユーザーの消費期間のために彼または彼女の上流プロビジョニングまたはダウンストリーム帯域幅（「ユーザー・消費しきい値」）の一定割合よりも大きく消費しなければなりません「）。ユーザーの消費しきい値は、上流または下流の帯域幅プロビジョニング彼または彼女の合計の特定の割合のユーザーの消費量として測定されます。その帯域幅は、特定のモデムは、顧客が購入したティア（住宅/個人、商用、など）に基づいて達成することができる最大速度です。ユーザは、上流下流の50 Mbpsおよび10 Mbpsの速度でサービスを購入した場合、例えば、その後、彼または彼女のプロビジョニング下流速度は50Mbpsであり、プロビジョニング上流の速度は10Mbpsです。ユーザーの消費しきい値は、特定のユーザーアカウントのプロビジョニング帯域幅の割合ではなく、静的な値であるため、より高速な階層のユーザーが対応してより高いユーザー・消費しきい値を持っていることに注意することも重要です。最後に、ユーザーの消費時間は分単位で測定されます。
Following lab tests, simulations, technical trials, customer feedback, vendor evaluations, and an independent third-party consulting analysis, we have determined that the appropriate starting point for the User Consumption Threshold is 70 percent of a subscriber's provisioned upstream or downstream bandwidth, and that the appropriate starting point for the User Consumption Duration is 15 minutes (this has been further validated in our full deployment). That is, when a subscriber uses an average of 70 percent or more of his or her provisioned upstream or downstream bandwidth over a particular 15-minute period, that user is then in an Extended High Consumption State. Therefore, this is a consumption-based threshold and not a peak-speed-based threshold. Thus, the Extended High Consumption State is not tied to whether a user has bursted once or more above this 70% threshold for a brief moment. Instead, it is consumption-based, meaning that a certain bitrate must be exceeded over at least the entire User Consumption Duration.
ラボテスト、シミュレーション、技術的な試験では、顧客からのフィードバック、ベンダーの評価、および独立した第三者のコンサルティング分析の後、我々はユーザーの消費しきい値のための適切な出発点は、加入者のプロビジョニング上流または下流の帯域幅の70％である、と判断していますユーザーの消費期間のための適切な出発点は15分であること（これはさらに、当社の完全な展開で検証されています）。すなわち、加入者が特定の15分かけて、彼または彼女の上流または下流のプロビジョニング帯域幅の70％以上の平均値を使用する場合、である、そのユーザは、拡張高消費状態で、次にです。したがって、これは、消費ベースの閾値はなく、ピーク速度に基づく閾値です。したがって、拡張、高消費状態は、ユーザが一瞬のために、この70％の閾値を超えて1回以上破裂したかどうかに縛られていません。その代わりに、特定のビットレートは、少なくとも全体のユーザーの消費時間を超える超過しなければならないことを意味し、消費ベースです。
The User Consumption Thresholds have been set sufficiently high that using the HSI connection for Voice over IP (VoIP), gaming, web surfing, or most streaming video cannot alone cause subscribers to our standard-level HSI service to exceed the User Consumption Threshold. For example, while one of Comcast's common HSI service tiers has a provisioned downstream bandwidth of 22 Mbps today, streaming video (even some HD video) from Hulu uses less than 2.5 Mbps, a Vonage or Skype VoIP call uses less than 131 kbps, and streaming music uses less than 128 kbps (in this example, 70 percent of 22 Mbps is 15.4 Mbps). As noted above, these values are subject to change as necessary in the same way that specific anti-spam or other network management practices are adjusted to address new issues that arise, or should unexpected software bugs or other problems arise.
ユーザーの消費しきい値は、IP（VoIP）の、ゲーム、ウェブサーフィン、またはほとんどのストリーミングビデオボイスオーバーのためのHSI接続を使用して、当社の標準レベルHSIサービスへの単独の原因加入者は、ユーザーの消費しきい値を超えないことを十分に高く設定されています。 Comcastの共通HSIサービス階層の一つは、Huluのから22 Mbpsでのプロビジョニング下り帯域幅今日、ストリーミングビデオ（さらにいくつかのHDビデオを）持っていながら、例えば、2.5未満Mbpsの、Vonageのか、SkypeのVoIP通話未満131 kbpsのを使用し、を使用していますストリーミング音楽未満128 kbpsの（この例では、22 Mbpsでの70％が15.4 Mbpsである）を使用します。上述したように、これらの値は、特定のアンチスパムやその他のネットワーク管理慣行が生じ、または予期しないソフトウェアのバグやその他の問題が発生しなければならない新たな課題に対処するために調整されているのと同じように、必要に応じて変更することがあります。
Based on data collected from the trial markets where the new congestion management practices were tested (further validated in our full deployment), on average less than one-third of one percent of subscribers have had their traffic priority status changed to the BE state on any given day. For example, in Colorado Springs, CO, the largest test market, on any given day in August 2008, an average of 22 users out of 6,016 total subscribers in the trial had their traffic priority status changed to BE at some point during the day.
新しい輻輳管理の実践を試験した臨床試験市場から収集したデータに基づいて、（さらに、当社の完全な展開で検証）、平均的に加入者の1％未満の三分の一は、そのトラフィックの優先順位の状態がどの上BE状態に変更されました日与えられました。たとえば、コロラドスプリングス、CO、最大のテスト市場において、2008年8月任意の日に、裁判で6016人の総加入者のうち22人のユーザーの平均は、そのトラフィックの優先順位ステータスは日中のある時点でなるように変更していました。
A user's traffic is released from a BE state when the user's bandwidth consumption drops below 50 percent of his or her provisioned upstream or downstream bandwidth for a period of approximately 15 minutes. These release criteria are intended to minimize (and hopefully prevent) user QoS oscillation, i.e., a situation in which a particular user could cycle repeatedly between BE and PBE. Thus, without this lower release criteria, we were concerned that certain users would oscillate between BE and PBE states for an extended period, without clear benefit to the system and other users, and would place an unnecessary signaling burden on the system. NetForecast, Inc., an independent consultant retained to provide analysis and recommendations regarding Comcast's trials and related congestion management work, suggested this approach, which has worked well in our trials, lab testing, and subsequent national deployment.
ユーザーの帯域幅消費量は約15分の期間のための彼または彼女の上流または下流のプロビジョニング帯域幅の50％以下に低下すると、ユーザーのトラフィックは、BE状態から解放されます。これらのリリース基準は最小（かつできれば防止）することが意図されているユーザのQoS振動、特定のユーザが繰り返しBEとPBE間のサイクル可能性があった、すなわち、状況。したがって、この低放出基準なしに、我々は、特定のユーザがシステムへの明確な利点と、他のユーザーせずに、長期間BEとPBEの状態の間で発振すると、システム上の不要なシグナリング負担をかけるだろうと懸念していました。 NetForecast社、独立したコンサルタントが、Comcastの試練と関連輻輳管理作業に関する分析と提言を提供するために、保持し、この私たちの試験でうまく働いているアプローチは、ラボのテスト、およびそれに続く全国展開を示唆しました。
Simply put, there are four steps for determining whether the traffic associated with a particular cable modem is designated as PBE or BE:
簡単に言えば、特定のケーブルモデムに関連するトラフィックがPBEまたはBEとして指定されているかどうかを判断するための4つのステップがあります。
2. If yes, determine whether any users are in an Extended High Consumption State.
2.はい場合は、どのユーザーが拡張、高消費状態にあるかどうかを判断します。
3. If yes, change those users' traffic to BE from PBE. If the answer at either step one or step two is no, no action is taken.
3.はい場合は、PBEからのものであると、それらのユーザのトラフィックを変更します。ステップ1またはステップ2のどちらかの答えがノーであれば、何もアクションは取られません。
4. If a user's traffic has been designated BE, check user consumption at the next interval. If user consumption has declined below the predetermined threshold, reassign the user's traffic as PBE. If not, recheck at the next interval.
4.ユーザーのトラフィックは、次の間隔でユーザーの消費量をチェックし、BE指定されている場合。ユーザーの消費量が所定の閾値を下回った場合は、PBEなど、ユーザーのトラフィックを再割り当てします。ない場合は、次の間隔で再確認してください。
In cases where a CMTS regularly enters a Near Congestion State, and where congestion subsequently does occur, but where no users match the criteria to be classified in an Extended High Consumption State, this may indicate the congestion observed is regularly occurring, rather than unpredictable congestion. As such, this may be an additional data point in favor of considering whether and when to add capacity.
CMTSは、定期的に近く輻輳状態となり、輻輳が続いて発生した場合にどのユーザが条件に一致しない場合、しかし、拡張高消費状態に分類される場合、これは定期的にではなく、予測不可能な輻輳よりも、発生している観察輻輳を示すことができます。そのため、これは、いつ、容量を追加するかどうかを検討するのに有利な追加のデータ点であってもよいです。
Figure 2 graphically depicts how this congestion management process works, using an example of a situation where upstream port utilization may be reaching a Near Congestion State (the same diagram, with different values in the appropriate places, could be used to depict the management process for downstream ports, as well):
図2は、グラフィカルストリームポート使用率が適切な場所に異なる値で、（同じ図を近く輻輳状態に到達することができる状況の例を使用して、ための管理プロセスを描写するために使用することができ、この輻輳管理プロセスがどのように機能するかを示しますダウンストリームポート、同様）。
Figure 2: Upstream Congestion Management Decision Flowchart
図2：上流輻輳管理の意思決定フローチャート
/\
+------------+ / \ +---------+ +---------+
| Start | / \ | | / /
| Congestion | / \ | | / /
| Management +-->+ Question +--YES-->| Result |--THEN-->/ Action /
| Process | \ #1 / | #1 | / #1 /
| | \ / | | / /
+------------+ \ / +---------+ +---------+
\/ |
| THEN
NO |
| \/
\/ /\
+---------+ / \
| | / \
| | / \
| Result |<-------------NO------------+ Question +
| #2 | \ #2 /
| | \ /
+---------+ \ /
\/
|
YES
|
/\ \/
+---------+ / \ +---------+
| | / \ | |
| | / \ THEN, AT | |
| Result |<--YES--+ Question + <---NEXT ANALYSIS------+ Result |
| #4 | \ #3 / POINT /\ | #3 |
| | \ / | | |
+---------+ \ / | +---------+
\/ |
| |
+------------NO-------------+
KEY TO FIGURE 2 ABOVE:
上の図2の鍵：
Question #1: Is the CMTS Upstream Port Utilization at an average of OVER 70% for OVER 15 minutes?
質問＃1：OVER 15分間の70％以上の平均で、CMTSアップストリームポートの使用状況はありますか？
Result #1: CMTS marked in a Near Congestion State, indicating congestion *may* occur soon.
結果＃1：* *すぐに発生する可能性があり混雑を示し、近く輻輳状態でマークCMTS。
Action #1: Search most recent analysis timeframe (approx. 15 mins.) of IPDR usage data.
アクション＃1：検索最新の分析の時間枠IPDR使用データの（約15分。。）。
Question #2: Are any users consuming an average of OVER 70% of provisioned upstream bandwidth for OVER 15 minutes?
質問＃2：OVER 15分間プロビジョニングアップストリーム帯域幅の70％以上の平均を消費するすべてのユーザーがいますか？
Result #2: No action taken.
結果＃2：処置は取られません。
Result #3: Change user's upstream traffic from Priority Best Effort (PBE) to Best Effort (BE).
結果＃3：ベストエフォート（BE）への優先ベストエフォート（PBE）から変更して、ユーザのアップストリームトラフィック。
Question #3: Is the user in Best Effort (BE) consuming an average of LESS THAN 50% of provisioned upstream bandwidth over a period of 15 minutes?
質問＃3：15分の期間にわたってプロビジョニングアップストリーム帯域幅の50％未満の平均を消費する（BE）ベストエフォートでのユーザーですか？
Result #4: Change user's upstream traffic back to Priority Best Effort (PBE) from Best Effort (BE).
結果＃4：バックベストエフォート（BE）から優先ベストエフォート（PBE）に変更し、ユーザのアップストリームトラフィック。
Figure 2
図2
When a CMTS port is in a Near Congestion State and a cable modem connected to that port is in an Extended High Consumption State, that cable modem's traffic is designated as BE. Depending upon the level of utilization on the CMTS port, this designation may or may not result in the user's traffic being delayed or, in extreme cases, dropped before PBE traffic is dropped. This is because of the way that the CMTS handles traffic. Specifically, CMTS ports have what is commonly called a "scheduler" that puts all the packets coming from or going to cable modems on that particular port in a queue and then handles them in turn. A certain number of packets can be processed by the scheduler in any given moment; for each time slot, PBE traffic is given priority access to the available capacity, and BE traffic is processed on a space-available basis.
CMTSポートが近く輻輳状態にあり、そのポートに接続されたケーブルモデムは、拡張、高消費状態にあるときは、そのケーブルモデムのトラフィックは、BEとして指定されています。 CMTSポートの使用状況のレベルに応じて、この指定は、または遅れたり、PBEのトラフィックがドロップされる前に、極端な場合には、廃棄されるユーザーのトラフィックが得られない場合があります。これは、CMTSがトラフィックを処理する方法です。具体的には、CMTSポートは、一般的に、すべてのパケットがから来るか、キューにその特定のポート上のケーブルモデムに行く置き、その後、順番にそれらを扱う「スケジューラ」と呼ばれるものを持っています。パケットの特定の数は、任意の所与の瞬間に、スケジューラによって処理することができます。タイムスロットごとに、PBEトラフィックは利用可能な容量への優先アクセスを付与され、トラフィックはスペース利用可能な単位で処理されること。
A rough analogy would be to busses that empty and fill up at incredibly fast speeds. As empty busses arrive at the figurative "bus stop" -- every two milliseconds in this case -- they fill up with as many packets as are waiting for "seats" on the bus, to the limits of the bus' capacity. During non-congested periods, the bus will usually have several empty seats, but during congested periods, the bus will fill up and packets will have to wait for the next bus. It is during the congested periods that BE packets will be affected. If there is no congestion, packets from a user in a BE state should have little trouble getting on the bus when they arrive at the bus stop. If, on the other hand, there is congestion in a particular instance, the bus may become filled by packets in a PBE state before any BE packets can get on. In that situation, the BE packets would have to wait for the next bus that is not filled by PBE packets. In reality, this all takes place in two-millisecond increments, so even if the packets miss 50 "busses", the delay will only be about one-tenth of a second.
ラフなアナロジーは、空バスになると信じられないほど速い速度でいっぱいでしょう。この場合内の各2つのミリ秒 - - 空のバスは比喩的な「バス停」に到着したようバスの能力の限界まで、バス上の「席」を待っていると、彼らはできるだけ多くのパケットでいっぱい。非混雑期間中、バスは通常、いくつかの空の席を持っていますが、混雑期間中、バスがいっぱいになり、パケットが次のバスを待つ必要があります。これは、影響を受けることになるパケットBE混雑期間中です。輻輳がない場合は、BEの状態で、ユーザからのパケットは、少し問題彼らはバス停に到着したときのバスに乗るを持っている必要があります。一方、特定のインスタンスでの輻輳がある場合は、バスは、任意のBEパケットが乗ることができる前にPBE状態でパケットによって埋めなることがあります。そのような状況では、BEパケットは、PBEパケットによって満たされていない次のバスを待たなければなりません。実際には、これはすべての2ミリ秒単位で行われますので、パケットは50「バス」を逃した場合でも、遅延はわずか秒の10分の1程度になります。
During times of actual network congestion, when packets from BE traffic might be intermittently delayed, there is a variety of effects that could be experienced by a user whose traffic is delayed, depending upon what applications he or she is using. Typically, a user whose traffic is in a BE state during actual congestion may find that a webpage loads sluggishly, a peer-to-peer upload takes somewhat longer to complete, or a VoIP call sounds choppy. Of course, the same thing could happen to the customers on a port that is congested in the absence of any congestion management; the difference here is that the effects of any such delays are shifted toward those who have been placing the greatest burden on the network, instead of being distributed randomly among the users of that port without regard to their consumption levels. As a matter of fact, our studies concluded that the experience of the PBE subscribers improves when this congestion management system is enabled. This conclusion is based on network measurements, such as latency.
BEトラフィックからのパケットが断続的に遅れる場合がございます、実際のネットワークの混雑の時間の間に、トラフィックが彼または彼女が使用しているアプリケーションに応じて、遅延しているユーザーが経験することができ、さまざまな効果があります。一般的に、実際の輻輳時のトラフィックがあるBEの状態で、ユーザは、Webページのロード緩慢に、ピア・ツー・ピアのアップロードが完了するまでに多少時間がかかることがあり、またはVoIP通話が途切れ途切れに聞こえます。もちろん、同じことは、任意の輻輳管理の不存在下で混雑しているポート上の顧客に起こることができます。ここでの違いは、どのような遅延の影響は、ネットワーク上の最も大きな負担をかけるされているのではなく、彼らの消費レベルに関係なく、そのポートのユーザーの間でランダムに分布している人の側にシフトしていることです。実際のところ、私たちの研究は、この輻輳管理システムが有効になっている場合PBE加入者の経験が改善されることを結論付けました。この結論は、待ち時間などネットワーク測定値に基づいています。
NetForecast explored the potential risk of a worst-case scenario for users whose traffic is in a BE state: the possibility of "bandwidth starvation" in the theoretical case where 100 percent of the CMTS bandwidth is taken up by PBE traffic for an extended period of time. In theory, such a condition could mean that a given user whose traffic is designated BE would be unable to effectuate an upload or download (as noted above, both are managed separately) for some period of time. However, when these management techniques were tested, first in company testbeds and then in our real-world trials conducted in the five markets (further validated in our full deployment), such a theoretical condition did not occur. In addition, our experience with the system as fully deployed in our production network demonstrates that these management practices have very modest real-world impacts. In addition, Comcast did not receive a single customer complaint, in any of the trial markets, that could be traced to this congestion management system, despite having broadly publicized these trials. In our subsequent national deployment into our production network, we still have yet to find a specific complaint that can be traced back to the effect of this congestion management system.
CMTS帯域幅の100％が長期にわたってPBEトラフィックに取り込まれる理論上の場合は、「帯域幅の飢餓」の可能性：NetForecastはBEトラフィック状態にあるユーザーのための最悪のシナリオの潜在的なリスクを探求しました時間。理論的には、このような状態は、（上記のように、両者が別々に管理されているよう）しばらくの間トラフィックが指定されているBE特定のユーザーがアップロードを実現またはダウンロードすることができないであろうことを意味するかもしれません。しかし、これらの管理技術は、試験した最初の会社のテストベッドで、その後、（さらに、当社の完全な展開で検証）5つの市場で行われ、当社の実世界の臨床試験では、このような理論的な状態が発生しませんでした。また、などの完全生産ネットワークで展開システムとの我々の経験は、これらの管理業務は非常に控えめな実世界の影響を持っていることを示しています。また、Comcastは広くこれらの試験を公表したにも関わらず、この輻輳管理システムにさかのぼることができトライアル市場、のいずれかで、単一の顧客の苦情を受けませんでした。当社の生産ネットワークへの私たちの、その後の全国展開では、我々はまだ、この輻輳管理システムの効果にさかのぼることができ、特定の苦情を見つけるためには至っていません。
Comcast continues to monitor how user traffic is affected by these new congestion management techniques and will make the adjustments necessary to ensure that all Comcast HSI customers have a high-quality Internet experience.
Comcastは、ユーザトラフィックは、これらの新しい輻輳管理技術によって影響され、すべてのComcastのHSIの顧客は、高品質のインターネット体験を持っていることを確保するために調整が必要になりますどのように監視し続けます。
The above-mentioned functions are carried out using three different types of application servers, supplied by three different vendors. As mentioned above, these servers are installed near Comcast's regional network routers. The exact locations of these servers are not particularly relevant to this document, as this information does not change the fact that the servers manage individual CMTS ports.
上記機能は、3つの異なるベンダによって供給されたアプリケーション・サーバーの3種類を用いて行われます。前述したように、これらのサーバーは、Comcastの地域ネットワークルーターの近くに設置されています。この情報はサーバが個々のCMTSポートを管理しているという事実を変更しないように、これらのサーバの正確な位置は、本文書に特に関係ありません。
The first application server is an IPDR server, which collects relevant cable modem volume usage information from the CMTS, such as how many aggregate upstream or downstream bytes a subscriber uses over a particular period of time. IPDR has been adopted as a standard by many industry organizations and initiatives, such as CableLabs, the Alliance for Telecommunications Industry Solutions (ATIS), the International Telecommunication Union (ITU), and the Third Generation Partnership Project (3GPP), among others. The IPDR software deployed was developed by Active Broadband Networks, and is noted as the Statistics Collection Server in Figure 3.
最初のアプリケーションサーバは、加入者が特定の期間にわたって使用する方法多くの凝集体の上流または下流のバイトとしてCMTS、から関連するケーブルモデムボリュームの使用状況に関する情報を収集IPDRサーバ、です。 IPDRは、とりわけ、このようCableLabsの、電気通信業界別ソリューションのための同盟（ATIS）、国際電気通信連合（ITU）、および第三世代パートナーシッププロジェクト（3GPP）など、多くの業界団体との取り組みにより、標準として採用されています。展開IPDRソフトウェアは、Activeブロードバンドネットワークによって開発された、および図3の統計収集サーバーとして注目されています。
The second application server is the Congestion Management server, which uses the Simple Network Management Protocol (SNMP) [RFC3410] to measure CMTS port utilization and detect when a port is in a Near Congestion State. When this happens, the Congestion Management server then queries the relevant IPDR data for a list of cable modems meeting the criteria set forth above for being in an Extended High Consumption State. The Congestion Management server software deployed was developed by Sandvine.
第二のアプリケーションサーバは、CMTSポートの使用率を測定し、ポートが近く輻輳状態にあるときを検出するために簡易ネットワーク管理プロトコル（SNMP）[RFC3410]を使用して輻輳管理サーバ、です。これが発生すると、輻輳管理サーバは、拡張、高消費状態にあるため、上記の基準を満たすケーブルモデムのリストについては、関連するIPDRデータを照会します。展開輻輳管理サーバソフトウェアは、Sandvine社によって開発されました。
If one or more users meet the criteria to be managed, then the Congestion Management server notifies a third application server, the PCMM application server, as to which users have been in an Extended High Consumption State and whose traffic should be treated as BE. The PCMM servers are responsible for signaling a given CMTS to set the traffic for specific cable modems with a BE QoS, and for tracking and managing the state of such CMTS actions. If no users meet the criteria to be managed, no users will have their traffic managed. The PCMM software deployed was developed by Camiant, and is noted as the QoS Server in Figure 3.
1人以上のユーザーが、基準が管理されるように満たしている場合、ユーザーはそのトラフィックBEとして扱われるべきである拡張大量消費国とされてきたためにどのように、その後、輻輳管理サーバは、第3のアプリケーション・サーバ、PCMMアプリケーションサーバに通知します。 PCMMサーバは、BEのQoSを持つ特定のケーブルモデムのための、そのようなCMTSアクションの状態を追跡し、管理するためのトラフィックを設定するために与えられたCMTSに信号を送るための責任があります。何のユーザーが管理すべき基準を満たしていない場合、ユーザーは自分のトラフィックを管理していません。展開PCMMソフトウェアはCamiantによって開発された、および図3のQoSサーバとして注目されています。
Figure 3 graphically depicts the high-level management flows among the congestion management components on Comcast's network, as described above:
図3は、グラフ上に記載したように、高レベルの管理は、Comcastのネットワーク上の輻輳管理コンポーネント間で流れる。示します。
Figure 3: Simplified Diagram Showing High-Level Management Flows Relevant to the System
図3：簡体示す図ハイレベル管理システムに関連フロー
+---------------+ +---------------+
| Congestion | Instruct QoS Server | QoS |
| Management |******to Change QoS for****>| Server |
| Server | a Device | |
+----+---+------+ +-------+-------+
/\ /\ *
| | Relay Selected *
X +---Statistics: Bytes---+ QoS Action:
| Up/Down by Device | Change from PBE
X +-------+-------+ to BE, or from
| | Statistics | BE to PBE
X | Collection | *
Periodic SNMP | Server | *
Requests to +---------------+ *
Check CMTS Port /\ *
Utilization | *
Levels Statistics Sent *
| Periodically From CMTS *
X | *
| +-----------+-----------+ *
+-X-X-X-X-X-X->| CMTS in Headend |<********
+-----------------------+
H /\ /\ H
H Internet Traffic H
H to/from User H
H \/ \/ H
/+---------------------+\
/ | User's +---------+ |\
/ | Home | Cable | | \
| | Modem | |
============ | +---------+ |
= Notes: = +----------------------+
= ========================================================
= 1 - Statistics Collection Servers use IP Detail Records (IPDR). =
= 2 - QoS Servers use PacketCable Multimedia (PCMM) =
= to set QoS gates on the CMTS. =
= 3 - This figure is a simplification of the actual network and =
= servers, which included redundancies and other complexities =
= not necessary to depict the functional design. =
===================================================================
Figure 3
Comcast started design and development of this new protocol-agnostic congestion management system in March 2008. Comcast shared the design with the IETF and others in the Internet community, as well as with an independent consultant, incorporating feedback we received into the final design. Following lab testing, the system was tested in Comcast's production network in trial markets between June and September 2008. Comcast's production network transition to this new protocol-agnostic congestion management system began in October 2008 and was completed on December 31, 2008.
ComcastはComcastのは、我々は最終的な設計に受け取ったフィードバックを取り入れ、インターネットコミュニティでのIETFや他の人とだけでなく、独立したコンサルタントとデザインを共有2008年3月にこの新しいプロトコルに依存しない輻輳管理システムの設計と開発を開始しました。ラボ試験の後、システムはこの新しいプロトコルに依存しない輻輳管理システムへのComcastの生産ネットワークの移行が2008年10月に始まり、2008年12月31日に終了した2008年6月と9月の間裁判市場でComcastの生産ネットワークで試験しました。
As described herein, the new approach does not manage congestion by focusing on managing the use of specific protocols. Nor does this approach use TCP "reset packets" [RFC3360]. Rather, the system acts such that during periods when a CMTS port is in a Near Congestion State, the system (1) identifies the subscribers on that port who have consumed a disproportionate amount of bandwidth over the preceding 15 minutes and (2) lowers the priority status of those subscribers' traffic to BE status until those subscribers meet the release criteria. During periods of actual congestion, the system handles PBE traffic before BE traffic. Comcast's trials and subsequent national deployment indicate that this new congestion management system ensures a quality online experience for all of Comcast's HSI customers.
本明細書に記載するように、新しいアプローチは、特定のプロトコルの使用を管理するに焦点を当てることによって輻輳を管理しません。 NORこのアプローチの使用TCPは、[RFC3360]「パケットをリセット」ん。むしろ、システムは、CMTSポートが近く輻輳状態にあるときに期間中、システム（1）は、先行する15分かけて帯域幅の不均衡な量を消費し、（2）が低下している、そのポート上で加入者を識別するように作用しますこれらの加入者が放出基準を満たすまで、これらの加入者のトラフィックの優先順位ステータスがステータスであることを。実際の混雑の期間中、システムは、BEトラフィックの前にPBEのトラフィックを処理します。 Comcastの裁判とその後の全国展開は、この新たな輻輳管理システムは、ComcastのHSIの顧客のすべてのための品質のオンライン体験を保証していることを示しています。
This system was developed to cope with somewhat "normal" occurrences of congestion that could occur on virtually any IP network. It should also be noted, however, that such a system could also prove particularly useful in the case of "exceptional network utilization" events that existing network usage models do not or cannot accurately predict. Some network operators refer to these exceptional events as "surges" in utilization, similar to sudden surges in demand in electrical power grids, with which many people may be familiar.
このシステムは、事実上すべてのIPネットワーク上で発生する可能性が渋滞のやや「通常」の発生に対処するために開発されました。また、このようなシステムは、既存のネットワークの使用モデルは、あるいは正確に予測することはできませんしていない「例外ネットワーク使用率」イベントの場合に特に有用であることが証明できたことに留意すべきです。いくつかのネットワークオペレータは、多くの人々はおなじみとすることができるとともに、電力グリッドの需要の急激なサージ、と同様に、利用中に「サージ」としてこれらの例外的なイベントを参照してください。
For example, in the case of a severe global pandemic, it may be expected that large swaths of the population may need to work remotely, via their Internet connection. In such a case, a largely unprecedented level of utilization may occur. In such cases, it may be helpful to have a flexible congestion management system that could adapt to this situation and help allocate network resources while additional capacity is being brought online or while a temporary condition persists.
例えば、深刻な世界的なパンデミックの場合には、人口の大スワスが自分のインターネット接続を介して、リモートで作業する必要があるかもしれないことを期待することができます。このような場合には、利用の大部分は前例のないレベルを生じる可能性があります。このような場合には、このような状況に適応し、追加の容量がオンラインにされている間、または一時的な状態が持続しながら、ネットワークリソースを割り当てる助けることができる柔軟な輻輳管理システムを持っていると便利かもしれません。
The main limitations of the system include:
システムの主な制限は次のとおりです。
o The system is not an end-to-end congestion management system, nor does it enable one.
Oシステムは、エンドツーエンドの輻輳管理システムではなく、またそれが1を有効ありません。
o The system does not signal the presence of congestion to user applications or to all devices on the network path.
Oシステムは、ユーザ・アプリケーションまたはネットワークパス上のすべてのデバイスに輻輳が存在することを通知しません。
o The system does not explicitly enable additional user and/or application responses to congestion.
Oシステムは、明示的輻輳への追加のユーザおよび/またはアプリケーションの応答を有効にしません。
o The system does not enable distributed denial-of-service (DDoS) mitigation or other capabilities.
Oシステムは、分散型サービス拒否（DDoS）攻撃軽減または他の機能を有効にしません。
There are several new IETF working group efforts that are focused on the question of congestion and its effects, avoiding congestion, managing congestion, and communicating congestion information. This includes the Congestion Exposure (CONEX) working group, the Application Layer Transport Optimization (ALTO) working group, and the Low Extra Delay Background Transport (LEDBAT) working group. Should one or more of these working groups be successful in producing useful work, it is possible that the design or configuration of the system documented here may need to change. For example, this congestion management system does not currently have a way to take into account differing classes of data transfer, such as a class of data transfer that LEDBAT may specify, which may better yield to other traffic than existing transport protocols. In addition, CONEX may specify methods for this or other systems to signal congestion state or expected congestion to other parts of the network, and/or to hosts on either end of a particular network flow. Furthermore, it is conceivable that the result of current or future IETF work could obviate the need for such a congestion management system entirely.
、混雑を避け、混雑を管理し、渋滞情報を伝える、渋滞とその効果の問題に焦点を当てているいくつかの新しいIETFワーキンググループの努力があります。これは、輻輳露出（CONEX）ワーキンググループ、アプリケーション層トランスポートの最適化（ALTO）ワーキンググループ、および低余分な遅延の背景トランスポート（LEDBAT）ワーキンググループが含まれます。これらのワーキンググループの1つ以上が有用な作業を生産することに成功する必要があり、ここで文書化されたシステムの設計や構成を変更する必要があることも可能です。たとえば、この輻輳管理システムは、現在、このような優れた既存のトランスポートプロトコル以外のトラフィックをもたらすかもしれLEDBATを指定することができ、データ転送のクラスなどのデータ転送の口座異なるクラスに取る方法がありません。また、コーネックスは、ネットワークの他の部分に、及び/又は特定のネットワーク・フローの両端にホストに輻輳状態または予想される輻輳を通知するために、このための方法または他のシステムを指定することができます。さらに、現在または将来のIETF作業の結果は、完全な輻輳管理システムの必要性をなくすことができると考えられます。
It is important that an ISP secure access to the Congestion Management servers and the QoS Servers, as well as QoS signaling to the CMTSs, so that unauthorized users and/or hosts cannot make unauthorized changes to QoS settings in the network.
権限のないユーザーおよび/またはホストは、ネットワーク内のQoS設定への不正な変更を加えることができないように、それは、そのISPの安全な輻輳管理サーバとQoSサーバへのアクセスだけでなく、CMTSはにQoSシグナリングが重要です。
It is also important to secure access to the Statistics Collection Server since this contains IPDR-based byte transfer data that is considered private by end users on an individual basis. In addition, this data is considered ISP-proprietary traffic data on an aggregate basis. Access to the Statistics Collection Server should also be secured so that false usage statistics cannot be fed into the system. It is important to note that IPDR data contains a count of bytes sent and bytes received, by cable modem MAC address, over a given interval of time. This data does not contain things such as the source and/or destination Internet address of that data, nor does it contain the protocols used, ports used, etc.
個別にエンドユーザーがプライベートと見なされIPDRベースのバイトの転送データが含まれているので、統計収集サーバへのアクセスを確保することも重要です。また、このデータは集計に基づきISP独自のトラフィックデータを検討しています。偽の使用状況の統計をシステムに供給することができないように統計収集サーバへのアクセスも確保しなければなりません。 IPDRデータが送信されたバイト数が含まれており、所定の時間間隔で、ケーブルモデムのMACアドレスにより、受信バイトことに注意することが重要です。など、このデータは、そのデータのソースおよび/または宛先インターネットアドレスとして物事を含んでいません。また、使用されるプロトコルが含まれていない、使用するポート
The authors wish to acknowledge the hard work of the many people who helped to develop and/or review this document, as well as the people who helped deploy the system in such a short period of time.
著者は、開発および/または本文書だけでなく、時間のような短い期間でシステムを展開助けた人を確認するために助けた多くの人々のハードワークを認めることを望みます。
The authors also wish to acknowledge the following individuals for performing a detailed review of this document and/or providing comments and feedback that helped to improve and evolve this document:
著者らはまた、このドキュメントの詳細なレビューを行い、および/または本文書を改善し、進化に貢献したコメントやフィードバックを提供するための以下の個人を確認したいです：
- Kris Bransom
- クリスBransom
- Bob Briscoe
- ボブ・ブリスコー
- Lars Eggert
- ラースEggertの
- Ari Keranen
- アリKeranen
- Tero Kivinen
- TERO Kivinen
- Matt Mathis
- マット・マティス
- Stanislav Shalunov
- スタンはハリーの宇野V対引っ張っています
[COMCAST_P2PI_PAPER] Livingood, J. and R. Woundy, "Comcast's IETF P2P Infrastructure Workshop Position Paper", FCC Filings Comcast Network Management Proceedings, May 2008, <http://trac.tools.ietf.org/area/rai/trac/raw-attachment/ wiki/PeerToPeerInfrastructure/ 16%20ietf-p2pi-comcast-20080509.pdf>.
[COMCAST_P2PI_PAPER] Livingood、J.とR. Woundy、 "ComcastのIETF P2P基盤ワークショップポジションペーパー"、FCCファイリングComcastのネットワーク管理議事録、2008年5月、<http://trac.tools.ietf.org/area/rai/trac /生付着/ウィキ/ PeerToPeerInfrastructure / 16％20ietf-p2pi-Comcastの-20080509.pdf>。
[COMCAST_P2PI_PRES] Livingood, J. and R. Woundy, "Comcast's IETF P2P Infrastructure Workshop Presentation on May 28, 2008", FCC Filings Comcast Network Management Proceedings, May 2008, <http://trac.tools.ietf.org/area/rai/trac/raw-attachment/ wiki/PeerToPeerInfrastructure/02-Comcast-IETF-P2Pi.pdf>.
[COMCAST_P2PI_PRES] Livingood、J.とR. Woundy、 "2008年5月28日にComcastのIETF P2Pインフラワークショッププレゼンテーション"、FCCファイリングComcastのネットワーク管理議事録、2008年5月、<http://trac.tools.ietf.org/area /ライ/ tracの/生-アタッチメント/ウィキ/ PeerToPeerInfrastructure / 02-Comcastの-IETF-P2Pi.pdf>。
[DOCSIS_CM2CPE] CableLabs, "Data-Over-Cable Service Interface Specifications - DOCSIS 3.0 - Cable Modem to Customer Premise Equipment Interface Specification", DOCSIS 3.0 CM-SP-CMCIv3-I01-080320, March 2008, <http://www.cablelabs.com/cablemodem/specifications/ specifications30.html>.
[DOCSIS_CM2CPE] CableLabsの、 "データオーバーケーブルサービスインターフェイス仕様 - 顧客宅内機器インタフェース仕様のケーブルモデム - DOCSIS 3.0"、DOCSIS 3.0 CM-SP-CMCIv3-I01-080320、2008年3月、<のhttp：// WWW。 cablelabs.com/cablemodem/specifications/ specifications30.html>。
[DOCSIS_IPDR] Yassini, R., "Data-Over-Cable Service Interface Specifications - DOCSIS 2.0 - Operations Support System Interface Specification", DOCSIS 2.0 CM-SP-OSSIv2.0-C01- 081104, November 2008, <http://www.cablelabs.com/ cablemodem/specifications/specifications30.html>.
[DOCSIS_IPDR] Yassini、R.、 "データオーバーケーブルサービスインターフェイス仕様 - DOCSIS 2.0 - オペレーションサポートシステムインターフェース仕様"、DOCSIS 2.0 CM-SP-OSSIv2.0-C01- 081104、2008年11月、<のhttp：// www.cablelabs.com/ケーブルモデム/仕様/ specifications30.html>。
[DOCSIS_MULPI] CableLabs, "Data-Over-Cable Service Interface Specifications - DOCSIS 3.0 - MAC and Upper Layer Protocols Interface Specification", DOCSIS 3.0 CM-SP-MULPIv3.0-I11-091002, October 2009, <http:// www.cablelabs.com/cablemodem/specifications/ specifications30.html>.
[DOCSIS_MULPI] CableLabsの、 "データオーバーケーブルサービスインターフェイス仕様 - DOCSIS 3.0 - MAC上位層プロトコルインタフェース仕様"、DOCSIS 3.0 CM-SP-MULPIv3.0-I11-091002、2009年10月、<のhttp：// WWW .cablelabs.com /ケーブルモデム/仕様/ specifications30.html>。
[DOCSIS_OSSI] CableLabs, "Data-Over-Cable Service Interface Specifications - DOCSIS 3.0 - Operations Support System Interface Specification", DOCSIS 3.0 CM-SP-OSSIv3.0-I10- 091002, October 2009, <http://www.cablelabs.com/ cablemodem/specifications/specifications30.html>.
[DOCSIS_OSSI] CableLabsの、 "データオーバーケーブルサービスインターフェイス仕様 - DOCSIS 3.0 - オペレーションサポートシステムインターフェース仕様"、DOCSIS 3.0 CM-SP-OSSIv3.0-I10- 091002、2009年10月、<のhttp：//www.cablelabs .COM /ケーブルモデム/仕様/ specifications30.html>。
[DOCSIS_PHY] CableLabs, "Data-Over-Cable Service Interface Specifications - DOCSIS 3.0 - Physical Layer Specification", DOCSIS 3.0 CM-SP-PHYv3.0-I08-090121, January 2009, <http://www.cablelabs.com/cablemodem/ specifications/specifications30.html>.
[DOCSIS_PHY] CableLabsの、 "データオーバーケーブルサービスインターフェイス仕様 - DOCSIS 3.0 - 物理層仕様"、DOCSIS 3.0 CM-SP-PHYv3.0-I08-090121、2009年1月、<http://www.cablelabs.com /ケーブルモデム/仕様/ specifications30.html>。
[DOCSIS_SEC] CableLabs, "Data-Over-Cable Service Interface Specifications - DOCSIS 3.0 - Security Specification", DOCSIS 3.0 CM-SP-SECv3.0-I11-091002, March 2008, <http:// www.cablelabs.com/cablemodem/specifications/ specifications30.html>.
[DOCSIS_SEC] CableLabsの、 "データオーバーケーブルサービスインターフェイス仕様 - DOCSIS 3.0 - セキュリティ仕様"、DOCSIS 3.0 CM-SP-SECv3.0-I11-091002、2008年3月、<のhttp：// www.cablelabs.com/ケーブルモデム/仕様/ specifications30.html>。
[FCC_Congest_Mgmt_Ltr] Zachem, K., "Letter to the FCC Advising of Successful Deployment of Comcast's New Congestion Management System", FCC Filings Comcast Network Management Proceedings, January 2009, <http://fjallfoss.fcc.gov/ecfs/document/ view?id=6520192582>.
[FCC_Congest_Mgmt_Ltr] Zachem、K.、2009年1月、FCCファイリングComcastのネットワーク管理議事録、「Comcastの新しい輻輳管理システムの導入を成功の助言FCCへの手紙」、<http://fjallfoss.fcc.gov/ecfs/document/ ID = 6520192582>？表示します。
[FCC_Memo_Opinion] Martin, K., Copps, M., Adelstein, J., Tate, D., and R. McDowell, "FCC Memorandum and Opinion Regarding Reasonable Network Management", File No. EB-08-IH-1518 WC Docket No. 07-52, August 2008, <http://hraunfoss.fcc.gov/ edocs_public/attachmatch/FCC-08-183A1.pdf>.
【FCC_Memo_Opinion]マーティン、K.、コップス、M.、Adelstein、J.、テート、D.、およびR.マクダウェル、 "FCC覚書かつ合理的なネットワーク管理に関する意見" は、番号EB-08-IH-1518 WCファイル整理番号07から52まで、2008年8月、<http://hraunfoss.fcc.gov/ edocs_public / attachmatch / FCC-08-183A1.pdf>。
[FCC_Net_Mgmt_Response] Zachem, K., "Letter to the FCC Regarding Comcast's Network Management Practices", FCC Filings Comcast Network Management Proceedings, September 2008, <http:// fjallfoss.fcc.gov/ecfs/document/view?id=6520169715>.
[FCC_Net_Mgmt_Response] Zachem、K.、 "Comcastのネットワーク管理プラクティスに関するFCCへの手紙"、FCCファイリングComcastのネットワーク管理議事録、2008年9月、<のhttp：// fjallfoss.fcc.gov/ecfs/document/view?id=6520169715 >。
[IPDR_Standard] Cotton, S., Cockrell, B., Walls, P., and T. Givoly, "Network Data Management - Usage (NDM-U) For IP-Based Services. Service Specification - Cable Labs DOCSIS 2.0 SAMIS", IPDR Service Specifications NDM-U, November 2004, <http://www.ipdr.org/public/Service_Specifications/3.X/ DOCSIS(R)3.5-A.0.pdf>.
【IPDR_Standard]綿、S.、コックレル、B.、壁、P.、およびT. Givoly、 "ネットワーク・データ管理 - IPベースのサービスのための使用法（NDM-U）サービス仕様 - ケーブルラボDOCSIS 2.0 SAMIS"、 IPDRサービス仕様NDM-U、2004年11月、<http://www.ipdr.org/public/Service_Specifications/3.X/ DOCSIS（R）3.5-A.0.pdf>。
[PowerBoost_Specification] Comcast Cable Communications Management LLC, "Comcast PowerBoost Specification", Website Comcast.com, June 2010, <http://customer.comcast.com/Pages/ FAQListViewer.aspx?topic=Internet& folder=8b2fc392-4cde-4750-ba34-051cd5feacf0>.
[PowerBoost_Specification] Comcastのケーブルコミュニケーションズ・マネジメントLLC、 "コムキャストPowerBoost仕様"、ウェブサイトComcast.com、2010年6月、<http://customer.comcast.com/Pages/ FAQListViewer.aspx？話題=インターネット＆フォルダ= 8b2fc392-4cde-4750 -ba34-051cd5feacf0>。
[RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[RFC1633]ブレーデン、B.、クラーク、D.、およびS. Shenker、 "インターネットアーキテクチャにおける統合サービス：概要"、RFC 1633、1994年6月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[RFC2475]ブレイク、S.、ブラック、D.、カールソン、M.、デイヴィス、E.、王、Z.、およびW.ワイス、 "差別化サービスのためのアーキテクチャ"、RFC 2475、1998年12月。
[RFC3083] Woundy, R., "Baseline Privacy Interface Management Information Base for DOCSIS Compliant Cable Modems and Cable Modem Termination Systems", RFC 3083, March 2001.
[RFC3083] Woundy、R.、「ベースラインプライバシーDOCSIS準拠のケーブルモデムやケーブルモデム終端システムのためのインタフェースの管理情報ベース」、RFC 3083、2001年3月。
[RFC3360] Floyd, S., "Inappropriate TCP Resets Considered Harmful", BCP 60, RFC 3360, August 2002.
[RFC3360]フロイド、S.、 "有害考慮不適切なTCPリセット"、BCP 60、RFC 3360、2002年8月。
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002.
[RFC3410]ケース、J.、マンディ、R.、パーテイン、D.、およびB.スチュワート、 "インターネット標準の管理フレームワークのための序論と適用性声明"、RFC 3410、2002年12月。
[RFC5594] Peterson, J. and A. Cooper, "Report from the IETF Workshop on Peer-to-Peer (P2P) Infrastructure, May 28, 2008", RFC 5594, July 2009.
[RFC5594]ピーターソン、J.、およびA.クーパー、 "ピア・ツー・ピア（P2P）インフラストラクチャ上のIETFワークショップからの報告書、2008年5月28日"、RFC 5594、2009年7月。
Authors' Addresses
著者のアドレス
Chris Bastian Comcast Cable Communications One Comcast Center 1701 John F. Kennedy Boulevard Philadelphia, PA 19103 US EMail: chris_bastian@cable.comcast.com URI: http://www.comcast.com
クリス・バスティアンComcastのケーブルコミュニケーションズ一つコムキャストセンター1701ジョンF.ケネディ大通りフィラデルフィア、PA 19103米国電子メール：chris_bastian@cable.comcast.com URI：http://www.comcast.com
Tom Klieber Comcast Cable Communications 1306 Goshen Parkway West Chester, PA 19380 US EMail: tom_klieber@cable.comcast.com URI: http://www.comcast.com
トムKlieber Comcastのケーブルコミュニケーションズ1306ゴセンパークウェイウエストチェスター、PA 19380米国電子メール：tom_klieber@cable.comcast.com URI：http://www.comcast.com
Jason Livingood Comcast Cable Communications One Comcast Center 1701 John F. Kennedy Boulevard Philadelphia, PA 19103 US EMail: jason_livingood@cable.comcast.com URI: http://www.comcast.com
ジェイソンLivingood Comcastのケーブルコミュニケーションズ一つコムキャストセンター1701ジョンF.ケネディ大通りフィラデルフィア、PA 19103米国電子メール：jason_livingood@cable.comcast.com URI：http://www.comcast.com
Jim Mills Comcast Cable Communications One Comcast Center 1800 Bishops Gate Drive Mount Laurel, NJ 08054 US EMail: jim_mills@cable.comcast.com URI: http://www.comcast.com
ジム・ミルズComcastのケーブルコミュニケーションズ一つコムキャストセンター1800司教ゲートドライブマウントローレル、NJ 08054米国電子メール：jim_mills@cable.comcast.com URI：http://www.comcast.com
Richard Woundy Comcast Cable Communications 27 Industrial Avenue Chelmsford, MA 01824 US EMail: richard_woundy@cable.comcast.com URI: http://www.comcast.com
リチャードWoundy Comcastのケーブルコミュニケーションズ27インダストリアル・アベニューチェルムズフォード、MA 01824米国電子メール：richard_woundy@cable.comcast.com URI：http://www.comcast.com