[要約] RFC 6057は、Comcastのプロトコルに依存しない過負荷制御システムに関するものであり、その目的は、ネットワークの適切な利用と公平性を確保することです。
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
Comcastのプロトコルに依存しない混雑管理システム
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.
このドキュメントでは、2008年12月31日にこの混雑管理システムの展開を完了した米国Comcastの大規模なケーブルブロードバンドインターネットサービスプロバイダー（ISP）であるComcast Cableの混雑管理システムについて説明します。
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によって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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 Cableは、米国に拠点を置く大規模なブロードバンドインターネットサービスプロバイダー（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ネットワークでも混雑が発生する可能性があることに注意することが重要です。また、パケットを遅らせたりドロップしたりすることができます。Bob BriscoeがIETFメーリングリストで指摘したように、ある程度のパケット損失は正常および/または許容可能である可能性があります。0.0013％（1〜74,000パケット）の割合では、これよりもはるかに低い損失の数値を達成しようとする必要はありません。実際、フローが他の場所でボトルネックされていない場合、TCPはそのような損失レベルを取得するまでシステムを駆動します。代わりに、顧客は5つの個別の10 Mbps TCPフローを80 msのRTTでダウンロードしています。TCPは最大1〜3,000（3,000（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ネットワークの要素を指します。その結果、これらの用語の一部を確認する際には、図1（セクション7を参照）を参照すると役立つ場合があります。
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 High Speed Internet（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）にあるハードウェア。CMTを考える簡単な方法は、一方の側にインターフェイスがインターネットにつながり、もう一方の側が光学ノードと顧客に接続して、いわゆる「ラストマイル」ネットワークに接続するルーターとしてです。
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.
テレビ、ケーブルモデム（EMTAを含む）、トップボックスのセットなどの顧客前提機器（CPE）を接続するためにケーブルオペレーターが使用するケーブルの種類。このケーブルは、家庭内および家庭または顧客の前提の場所に走る「ラストマイル」ネットワークのセグメントで使用できます。さまざまな目的で使用される同軸ケーブルには多くのグレードがあります。さまざまな種類の同軸ケーブルが、ネットワーク上のさまざまな目的に使用されます。
A service/product offered by Comcast for delivering Internet service over a broadband connection.
ブロードバンド接続を介してインターネットサービスを提供するためにComcastが提供するサービス/製品。
Any device that resides at the customer's residence, connected to the Comcast network, whether controlled by Comcast or not.
Comcastによって制御されるかどうかにかかわらず、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]、[docsis_phy]、[docsis_mulpi]、[docsis_sec]、[docsis_ossi]に記載されているように、HFCネットワーク上でHSIサービスを有効にするために、ケーブルネットワーク上のコンポーネントを構築する必要がある方法を指定するケーブルラブによって開発された参照標準。これらの標準は、ケーブルモデムとCMTSの仕様を定義し、DOCSIS認定ケーブルモデムは、選択したベンダーとは無関係にDOCSIS認定CMTで動作します。ケーブルモデムとCMTSSの相互運用性により、顧客は小売店からDOCSIS認定モデムを購入し、ケーブルネットワークの家で使用することができます。すべてのDOCSIS関連標準は、CableLabs Webサイトのhttp://www.cablelabs.comで一般に公開されています。
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から収集され、さらに処理するためにサーバーに送信されます。追加情報は、http://www.ipdr.orgと[ipdr_standard]および[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ネットワークのコンポーネントは、同軸ケーブルを介して顧客のケーブルモデムに送信できる、またはその逆です。光ファイバーケーブルは、分布ハブを介して光ノードをCMTに接続し、同軸ケーブルは光ノードを顧客のケーブルモデムに接続します。
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の上流帯域幅をプロビジョニングしていると言われます。これは、多くの場合、業界用語で105/10サービスと呼ばれます。
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をネットワークに提供する1つの方法は、クラスまたはフローごとのトラフィックの種類を区別し、各タイプに優先順位を割り当てることです。ネットワークが混雑すると、優先度が高いとマークされているデータパケットは、サービスが提供される可能性が高くなります。
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.
信号が移動する方向の説明、この場合はユーザーからネットワークまで。アップストリームトラフィックは、ユーザーが電子メールの送信、別のコンピューターへのファイルの送信、デジタル写真Webサイトへの写真のアップロードなど、ネットワークに何かをアップロードしているときに発生します。
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は、米国ペンシルベニア州フィラデルフィアで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.
このワークショップに参加するために、興味のある参加者は、2008年5月9日に[comcast_p2pi_paper]で行った技術レビューチームに論文を提出するように求められました。その後、Comcastはこの貴重なワークショップに参加し、参加しました。ワークショップで、Comcastは、新しい混雑管理システム[comcast_p2pi_pres]のハイレベルデザインを概説し、参加者やインターネットコミュニティの他のメンバーからのコメントやその他のフィードバックを求めました（プレゼンテーションはIETFのP2PIメーリングリストにも投稿されました）。2008年5月のワークショップが後にトライアル市場でテストされ、本質的に2008年後半にComcastによって展開されたものであるという概要を説明しました。
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 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.
2008年8月のFCCドキュメント[FCC_MEMO_OPINION]に続いて、Comcastが高速インターネット（「HSI」）ネットワークで混雑を管理した方法について、ComcastはFCC [FCC_NET_MGMT_RESPONSE]に明らかにしました。2008年末までに[FCC_Congest_mgmt_ltr]を実装しました。これには、この新しいシステムに関与するしきい値が含まれます。このシステムが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.
1. Comcast Networkにインストールされているソフトウェアは、ComcastのHSIネットワークの個々のセグメントの集計トラフィック使用データを継続的に調べます。ComcastのHSIネットワークの特定のセグメントでの全体的な上流または下流の使用が事前に決められたレベルに達すると、ソフトウェアはステップ2に移動します。
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は、この混雑管理アプローチの計画を策定し、それらを調整し、実際の試験にさらしているために、何ヶ月もの間、かなりの努力をしました。市場試験はペンシルベニア州チェンバーズバーグで実施されました。バージニア州ウォレントン;フロリダ州レイクシティ;フロリダ州イーストオレンジ;2008年6月から9月までのコロラドスプリングス、コロラドスプリングス。これにより、一般的なアプローチの有用性を検証し、実質的な試験データを収集して、複数のバリエーションと代替製剤をテストすることができました。
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.
2番目の一般的なタイプの混雑は予測不可能な混雑であり、これは広範な理由で発生する可能性があります。1つの例は、ユーザーがすべて同時に特定のコンテンツにアクセスするために急いでいる可能性があり、そのコンテンツを提供するシステムが需要に追いつくことができない可能性がある現在のイベントによる可能性があります。別の例は、いくつかのネットワークパスが破壊されたり、損なわれたりしている局所的な災害によるものであり、多くのユーザーがトラフィックレベルで通常を大幅に上回ると互いに通信しようとしていることです。
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はネットワーク全体に3,200以上のCMTSSを展開し、1500万人以上のHSI加入者にサービスを提供しています。
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.
各CMTには、CMTSに入って出発するトラフィックを処理する複数の「ポート」があります。特に、Comcast HSIネットワークに展開されている各ケーブルモデムは、CMTSのポートを介してCMTに接続されています。これらのポートは、ケーブルモデム（下流）に情報を送信するか、ポートに接続されたケーブルモデム（上流）から情報を受信するかによって、「下流」ポートまたは「上流」ポートのいずれかです。（ここで使用される「ポート」という用語は、一般に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」）サーバー、渋滞管理サーバー、およびパケット可能なマルチメディア（「PCMM」）サーバーで構成されています。これらの機器のそれぞれの詳細については、以下のセクション7.4を参照してください。ただし、これらのサーバーの物理的な場所がRNRにあるにもかかわらず、サーバーは複数のCMTSで複数のポートと通信し、個別に管理して、このドキュメントに記載されているプラクティスを実現することに注意することが重要です。つまり、1つのCMTSポートでの帯域幅の使用は、本明細書に記載されている混雑管理慣行が別のCMTSポートのサブスクライバーに適用されるかどうかに影響を与えません。
Figure 1 provides a simplified graphical depiction of the network architecture just described: Figure 1: Simplified Network Diagram Showing High-Level Comcast
図1に、ちょうど説明したネットワークアーキテクチャの簡略化されたグラフィカルな描写を示します。図1：高レベルのComcastを示す簡略化されたネットワーク図
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サブスクライバーのケーブルモデムには「ブートファイル」があります。これは、基本的に、サービスが適切に機能することを保証するためにサブスクライバーのサービスに関する特定の情報を含む構成ファイルです。（注：個人情報はBootfileに含まれていません。サブスクライバーが購入したサービスに関する情報のみが含まれています。）たとえば、Bootfileには最大速度に関する情報が含まれています（このドキュメントでは、「プロビジョニングされた帯域幅」と呼ばれます。"）特定のモデムがティア（個人/住宅、商業など）に基づいて実現できること。ブートファイルは通常、ネットワークやその他の更新の変更を考慮するために時々リセットされます。これは通常、ネットワークから送信されたコマンドを介して、サブスクライバーの顕著なものなしで行われます。この新しい混雑管理システムへの移行に備えて、Comcastは、ケーブルモデムとの間のインターネットトラフィックの2つの品質（QOS）レベルを作成したHSI顧客のケーブルモデムに新しいブートファイルを送信しました：（1） "Priority Best努力 "（" pbe "）トラフィック;（2）「最善の努力」（「BE」）トラフィック。ケーブルモデムブートファイルの以前の変更と同様に、古いブートファイルを新しいブートファイルに置き換えるには、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は、特定のケーブルモデムから来る、または移動するすべてのインターネットトラフィックのデフォルトステータスです。トラフィックは、2つの条件の両方が満たされている場合にのみ、特定のケーブルモデムの場合に指定されます。o最初に、特定の期間にわたって測定されたCMTの特定の上流または下流ポートの使用レベルは、ポイントに近づいている必要があります。混雑はユーザーの経験を低下させる可能性があります。これを「うっ血状態に近い状態」と呼び、私たちが実施した技術試験に基づいて（完全な展開でさらに検証されています）、特定の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トラフィックに影響する前にトラフィックに影響します。
We now explain the foregoing in greater detail in the following sections.
次のセクションで、前述の詳細について説明します。
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がより多くのデータを収集し、広範なスケールに起因する追加の分析を実行するため、これらの値が時間とともに変化することはほぼ確実です新しいテクニックの使用。さらに、大規模なネットワークまたはソフトウェアシステムと同様に、ソフトウェアのバグや予期しないエラーが発生する可能性があり、ソフトウェアパッチやその他の是正措置が必要です。いつものように、これらの問題に関する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のネットワークに展開されている新しいCMTSSのいくつかの技術的な制限は、この期間がわずかに異なる場合があります）。したがって、15分間にわたって、ポートの上流帯域幅容量の平均70％以上またはポートの下流帯域幅容量の80％以上が利用されている場合、そのポートはほぼうっ血状態にあると判断されます。
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ポートは、最も忙しいものになることを予測する方法はありませんが、その日の比較的小さな部分でのみ、ほぼうっ血状態にあります。特定の日の特定のポートでの時間。さらに、試行データと運用の経験は、特定のポートがほぼうっ血状態にある場合でも、ポート利用期間中にネットワークが実際に混雑するインスタンスが少なく、パケットが断続的に遅延または削除される可能性のあるマネージドユーザーが少ないことを示しています。これらの混雑した期間中、以下で説明するように、あれば、効果があったとしても、ほとんど認識されていません。
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上流10 Mbpsのサービスを購入すると、プロビジョニングされたダウンストリーム速度は50 Mbpsで、プロビジョニング上流速度は10 Mbpsです。また、ユーザー消費のしきい値は特定のユーザーアカウントのプロビジョニングされた帯域幅の割合であり、静的値ではないため、高速層のユーザーはそれに応じてユーザー消費のしきい値が高いことに注意することも重要です。最後に、ユーザーの消費期間は数分で測定されます。
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.
ユーザー消費のしきい値は、Voice over IP（VoIP）、ゲーム、Webサーフィン、またはほとんどのストリーミングビデオのHSI接続を使用して、標準レベルのHSIサービスをユーザー消費のしきい値を超えることができないため、十分に高く設定されています。たとえば、Comcastの一般的なHSIサービスティアの1つには、今日22 Mbpsの下流帯域幅がプロビジョニングされていますが、Huluのストリーミングビデオ（HDビデオでも）が2.5 Mbps未満、VonageまたはSkype Voip Callは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.
新しい混雑管理慣行がテストされたトライアル市場から収集されたデータに基づいて（完全な展開でさらに検証されています）、平均してサブスクライバーの3分の1未満がトラフィックの優先順位ステータスをBE状態に変更しました。与えられた日。たとえば、2008年8月の任意の日に最大のテスト市場であるコロラドスプリングスでは、試験の合計6,016人の加入者のうち平均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状態の間で長期間振動することを心配しました。Comcastの試験と関連する混雑管理作業に関する分析と推奨事項を提供するために保持された独立したコンサルタントであるNetforeCast、Inc。は、このアプローチが私たちの試験、ラボテスト、およびその後の全国展開でうまく機能していることを示唆しました。
Simply put, there are four steps for determining whether the traffic associated with a particular cable modem is designated as PBE or BE:
簡単に言えば、特定のケーブルモデムに関連付けられているトラフィックがPBEとして指定されているのか、あるかを判断するための4つの手順があります。
1. Determine if the CMTS port is in a Near Congestion State.
1. CMTSポートがほぼうっ血状態にあるかどうかを判断します。
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のいずれかの回答がNOの場合、アクションは実行されません。
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. ユーザーのトラフィックが指定されている場合は、次の間隔でユーザーの消費を確認してください。ユーザーの消費が所定のしきい値を下回った場合、ユーザーのトラフィックを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.
CMTが定期的に近くの混雑状態に入る場合、およびその後の混雑が発生しますが、ユーザーが拡張された高消費状態で分類される基準と一致しない場合、これは、予測不可能な輻輳ではなく、観察されたうっ血が定期的に発生していることを示している可能性があります。。そのため、これは容量を追加するかどうか、いつ追加するかを検討することを支持する追加のデータポイントである可能性があります。
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：CMTS上流のポート利用は、15分以上で平均70％を超えるものですか？
Result #1: CMTS marked in a Near Congestion State, indicating congestion *may* occur soon.
結果＃1：CMTはほぼうっ血状態でマークされており、輻輳 *がすぐに発生する可能性があることを示しています。
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：プロビジョニングされた上流帯域幅の平均70％を15分以上消費しているユーザーはいますか？
Result #2: No action taken.
結果＃2：アクションが取られていません。
Result #3: Change user's upstream traffic from Priority Best Effort (PBE) to Best Effort (BE).
結果＃3：ユーザーのアップストリームトラフィックを優先順位のベストエフェクト（PBE）から最善の努力（BE）に変更します。
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％未満を消費していますか？
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トラフィックには利用可能な容量への優先アクセスが与えられ、BEトラフィックはスペースで利用可能なベースで処理されます。
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.
大まかな類似性は、空になり、信じられないほど速い速度でいっぱいのバスになります。空のバスが比fig的な「バス停」に到着すると、この場合は2ミリ秒ごとに、バスの「座席」を待っているのと同じくらい多くのパケットで、バスの容量までいっぱいになります。一時的な期間中、バスには通常いくつかの空の座席がありますが、混雑期間中はバスがいっぱいになり、パケットは次のバスを待つ必要があります。混雑した期間中、パケットが影響を受けます。混雑がない場合、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.
NetForeCastは、トラフィックがBE状態にあるユーザーの最悪のシナリオの潜在的なリスクを調査しました。CMTS帯域幅の100％が長期間のPBEトラフィックによって採用される理論的ケースでは、「帯域幅の飢vation」の可能性を調査しました。時間。理論的には、そのような条件は、トラフィックが指定されている特定のユーザーが、しばらくの間、アップロードまたはダウンロード（上記のように、両方とも個別に管理される）を影響を与えることができないことを意味します。ただし、これらの管理手法が最初に会社のテストベッドでテストされ、次に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.
最初のアプリケーションサーバーはIPDRサーバーであり、CMTSから関連するケーブルモデムボリューム使用情報を収集します。たとえば、サブスクライバーが特定の期間にわたって使用する上流または下流バイトの数などです。IPDRは、多くの業界組織や、CableLabs、Alliance for Telecommunications Industry Solutions（ATIS）、International Telecommunication Union（ITU）、第3世代パートナーシッププロジェクト（3GPP）などのイニシアチブによって標準として採用されています。展開されたIPDRソフトウェアは、アクティブなブロードバンドネットワークによって開発され、図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.
2番目のアプリケーションサーバーは、Simple Network Management Protocol（SNMP）[RFC3410]を使用してCMTSポートの使用率を測定し、ポートがほぼうっ血状態にあるときに検出する渋滞管理サーバーです。これが発生すると、混雑管理サーバーは、上記の高消費状態にあるために上記の基準を満たすケーブルモデムのリストの関連する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人または複数のユーザーが管理する基準を満たしている場合、混雑管理サーバーは、ユーザーが拡張された高消費状態にあり、そのトラフィックを扱う必要がある3番目のアプリケーションサーバーであるPCMMアプリケーションサーバーに通知します。PCMMサーバーは、特定のCMTSを信号して、QOSを使用して特定のケーブルモデムのトラフィックを設定し、そのような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は、2008年3月にこの新しいプロトコルに依存しない混雑管理システムの設計と開発を開始しました。Comcastは、インターネットコミュニティのIETFなどとデザインを共有し、最終的なデザインに受け取ったフィードバックを組み込んだ独立コンサルタントと共有しました。ラボテストに続いて、このシステムは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.
本明細書に記載されているように、新しいアプローチでは、特定のプロトコルの使用の管理に焦点を当てることにより、渋滞を管理していない。また、このアプローチはTCP「リセットパケット」を使用していません[RFC3360]。むしろ、システムは、CMTSポートがほぼうっ血状態にある期間中、システムが以前の15分間で不均衡な量の帯域幅を消費したそのポートのサブスクライバーを識別し、（2）を識別し、（2）それらのサブスクライバーのトラフィックの優先ステータスは、それらのサブスクライバーがリリース基準を満たすまでのステータスです。実際の輻輳の期間中、システムはトラフィックの前に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 このシステムは、エンドツーエンドの混雑管理システムではなく、そうではありません。
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が指定する可能性のあるデータ転送のクラスなど、さまざまなクラスのデータ転送を考慮する方法がありません。さらに、Conexは、ネットワークの他の部分、および/または特定のネットワークフローの両端でホストに輻輳状態または予想される輻輳を通知するために、このシステムまたは他のシステムのメソッドを指定する場合があります。さらに、現在または将来の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.
ISPが混雑管理サーバーとQoSサーバーへの安全なアクセス、およびCMTSSへのQoS信号を保護することが重要です。そのため、不正なユーザーやホストはネットワーク内の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ベースのバイト転送データが含まれているため、Statistics Collection Serverへのアクセスを保護することも重要です。さらに、このデータは、ISP専用のトラフィックデータと見なされます。Statistics Collection Serverへのアクセスも保護されているため、虚偽の使用統計がシステムに供給できないようにする必要があります。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
- クリス・ブランサム
- Bob Briscoe
- ボブ・ブリスコ
- Lars Eggert
- ラースエッガート
- Ari Keranen
- アリ・ケラネン
- Tero Kivinen
- テロキビネン
- Matt Mathis
- マット・マティス
- Stanislav Shalunov
- スタニスラフ・シャルノフ
[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.傷、「ComcastのIETF P2Pインフラストラクチャワークショップポジションペーパー」、FCCファイリングComcast Network Management Proceedings、2008年5月、<http://trac.ietf.org/are/rai/trac/ raw-attachment/ wiki/ 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.傷、「ComcastのIETF P2Pインフラストラクチャワークショップ2008年5月28日のプレゼンテーション」、FCCファイリングコムキャストネットワーク管理手続、2008年5月、<http://trac.tools.ietf.org/areaea/rai/trac/raw-attachment/wiki/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/仕様30.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/ cablemodem/specistations/specistations30.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：// wwwwwwwwwwww.cablelabs.com/cablemodem/仕様/仕様30.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/cablemodem/仕様/仕様30.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/cablemodem/仕様/仕様30.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/cablemodem/仕様/仕様30.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。、「Comcastの新しい混雑管理システムの成功した展開に関するFCCへの手紙」、FCCファイリングComcast Network Management Proceedings、2009年1月、<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] Martin、K.、Copps、M.、Adelstein、J.、Tate、D。、およびR. McDowell、「FCC覚書と合理的なネットワーク管理に関する意見」、ファイル番号EB-08-IH-1518 WCDocket No. 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 Network Management Proceedings、2008年9月、<http：// fjallfoss.fcc.gov/ecfs/document/view?id=652016971515>。
[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] Cotton、S.、Cockrell、B.、Walls、P。、およびT. Givoly、「ネットワークデータ管理-IPベースのサービスの使用（NDM -U）サービス仕様-Cable Labs Docsis 2.0 Samis」、IPDRサービス仕様NDM-U、2004年11月、<http://www.ipdr.org/public/service_spifications/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 Cable Communications Management LLC、「Comcast PowerBoost Specification」、Webサイトcomcast.com、2010年6月、<http://customer.comcast.com/pages/ faqlistviewer.aspx？トピック=インターネット＆フォルダー= 8b2ffc392-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] Braden、B.、Clark、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] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z.、およびW. Weiss、「差別化されたサービスの建築」、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]傷、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] Case、J.、Mundy、R.、Partain、D。、およびB. Stewart、「インターネット標準管理フレームワークの紹介と適用声明」、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] Peterson、J。and A. Cooper、「Peer-to-Peer（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
クリス・バスティアン・コムキャスケーブルコミュニケーションワン・コムキャス・センター1701ジョン・F・ケネディ・ブルバード・フィラデルフィア、ペンシルベニア州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
Tom Klieber Comcast Cable Communications 1306 Goshen Parkway West Chester、PA 19380 US Email：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
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
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
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
Richard Woundy Comcast Cable Communications 27 Industrial Avenue Chelmsford, MA 01824 US EMail: richard_woundy@cable.comcast.com URI: http://www.comcast.com
Richard Roundy Comcast Cable Communications 27 Industrial Avenue Chelmsford、MA 01824 US Email：richard_woundy@cable.comcast.com URI：http：//www.comcast.com