Network Working Group H. Balakrishnan
Request for Comments: 3124 MIT LCS
Category: Standards Track S. Seshan
CMU
June 2001
The Congestion Manager
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
Abstract
抽象
This document describes the Congestion Manager (CM), an end-system module that:
この文書では、輻輳マネージャ（CM）、エンド・システム・モジュールについて説明します。
(i) Enables an ensemble of multiple concurrent streams from a sender destined to the same receiver and sharing the same congestion properties to perform proper congestion avoidance and control, and
（i）は、同一の受信機宛の送信機から複数の同時ストリームの集合を有効にし、適切な輻輳回避や制御を行うために、同じ輻輳特性を共有し、そして
(ii) Allows applications to easily adapt to network congestion.
（ⅱ）のアプリケーションが簡単にネットワークの輻輳に適応することができます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [Bradner97].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC-2119 [Bradner97]に記載されているように解釈されます。
STREAM
ストリーム
A group of packets that all share the same source and destination IP address, IP type-of-service, transport protocol, and source and destination transport-layer port numbers.
すべて同じ送信元および宛先IPアドレスを共有するパケットのグループ、IPサービスタイプ、トランスポートプロトコル、ソースおよび宛先トランスポート層ポート番号。
MACROFLOW
MACROFLOW
A group of CM-enabled streams that all use the same congestion management and scheduling algorithms, and share congestion state information. Currently, streams destined to different receivers belong to different macroflows. Streams destined to the same receiver MAY belong to different macroflows. When the Congestion Manager is in use, streams that experience identical congestion behavior and use the same congestion control algorithm SHOULD belong to the same macroflow.
CM-有効すべて同じ輻輳管理およびスケジューリングアルゴリズムを使用してストリーム、および共有輻輳状態情報のグループ。現在、異なる受信機宛のストリームは異なるmacroflowsに属します。同じ受信機宛のストリームは異なるmacroflowsに属していてもよいです。輻輳マネージャを使用している場合は、その経験の同一混雑行動ストリームと同じmacroflowに属している必要があり、同じ輻輳制御アルゴリズムを使用します。
APPLICATION
応用
Any software module that uses the CM. This includes user-level applications such as Web servers or audio/video servers, as well as in-kernel protocols such as TCP [Postel81] that use the CM for congestion control.
CMを使用するすべてのソフトウェア・モジュール。これは、輻輳制御のためのCMを使用するようにWebサーバーまたはオーディオ/ビデオ・サーバなど、ユーザーレベルのアプリケーション、ならびにこのようなTCP [Postel81]として、カーネル内のプロトコルを含んでいます。
WELL-BEHAVED APPLICATION
行儀APPLICATION
An application that only transmits when allowed by the CM and accurately accounts for all data that it has sent to the receiver by informing the CM using the CM API.
正確にCMによって許可されたときにのみ送信アプリケーションは、それがCMのAPIを使用してCMを知らせることによって受信機に送信したことを、すべてのデータを占めています。
PATH MAXIMUM TRANSMISSION UNIT (PMTU)
PATHの最大伝送ユニット（PMTU）
The size of the largest packet that the sender can transmit without it being fragmented en route to the receiver. It includes the sizes of all headers and data except the IP header.
送信者は、それが受信機への途中でフラグメント化されずに送信できる最大パケットサイズ。これは、IPヘッダを除くすべてのヘッダとデータのサイズを含みます。
CONGESTION WINDOW (cwnd)
輻輳ウィンドウ（CWND）
A CM state variable that modulates the amount of outstanding data between sender and receiver.
送信側と受信側の間で未処理データの量を調節するCM状態変数。
OUTSTANDING WINDOW (ownd)
OUTSTANDING WINDOW（ownd）
The number of bytes that has been transmitted by the source, but not known to have been either received by the destination or lost in the network.
ソースによって送信されたではなく、宛先によって受信され、ネットワークで失われていることのいずれかが知られているバイトの数。
INITIAL WINDOW (IW)
INITIAL WINDOW（IW）
The size of the sender's congestion window at the beginning of a macroflow.
macroflowの先頭に送信者の輻輳ウィンドウのサイズ。
DATA TYPE SYNTAX
DATA TYPE SYNTAX
We use "u64" for unsigned 64-bit, "u32" for unsigned 32-bit, "u16" for unsigned 16-bit, "u8" for unsigned 8-bit, "i32" for signed 32-bit, "i16" for signed 16-bit quantities, "float" for IEEE floating point values. The type "void" is used to indicate that no return value is expected from a call. Pointers are referred to using "*" syntax, following C language convention.
我々は、符号付き32ビット、「I16」の符号なし8ビット、「I32」の符号なし16ビット、「U8」の符号なし32ビット、「U16」の符号なし64ビット、「U32」は、「U64」を使用します符号付き16ビット値のためのIEEE浮動小数点値について、「フロート」。タイプ「無効」は何の戻り値は呼び出しから期待されていないことを示すために使用されます。ポインタはC言語の慣習以下、「*」構文を使用して参照されています。
We emphasize that all the API functions described in this document are "abstract" calls and that conformant CM implementations may differ in specific implementation details.
私たちは、この文書に記載されているすべてのAPI関数は「抽象的」コールと準拠のCMの実装は、特定の実装の詳細が異なる場合があることを強調します。
The framework described in this document integrates congestion management across all applications and transport protocols. The CM maintains congestion parameters (available aggregate and per-stream bandwidth, per-receiver round-trip times, etc.) and exports an API that enables applications to learn about network characteristics, pass information to the CM, share congestion information with each other, and schedule data transmissions. This document focuses on applications and transport protocols with their own independent per-byte or per-packet sequence number information, and does not require modifications to the receiver protocol stack. However, the receiving application must provide feedback to the sending application about received packets and losses, and the latter is expected to use the CM API to update CM state. This document does not address networks with reservations or service differentiation.
このドキュメントで説明するフレームワークは、すべてのアプリケーションおよびトランスポートプロトコル間で輻輳管理を統合します。 CMは（等利用可能な骨材とあたりストリーム帯域ごとの受信機の往復回）混雑パラメータを維持し、アプリケーションがネットワーク特性について学習を可能にするAPIをエクスポートし、互いにCM、共有渋滞情報に情報を渡します、およびスケジュールデータ伝送。この文書は、独自の独立したバイト単位またはパケットシーケンス番号情報とアプリケーションとトランスポートプロトコルに焦点を当て、および受信機のプロトコルスタックを変更する必要はありません。しかし、受信側アプリケーションは、受信したパケットと損失約送信アプリケーションにフィードバックを提供する必要があり、後者は、CMの状態を更新するために、CMのAPIを使用することが期待されます。この文書では、予約やサービスの差別化とネットワークに対応していません。
The CM is an end-system module that enables an ensemble of multiple concurrent streams to perform stable congestion avoidance and control, and allows applications to easily adapt their transmissions to prevailing network conditions. It integrates congestion management across all applications and transport protocols. It maintains congestion parameters (available aggregate and per-stream bandwidth, per-receiver round-trip times, etc.) and exports an API that enables applications to learn about network characteristics, pass information to the CM, share congestion information with each other, and schedule data transmissions. When the CM is used, all data transmissions subject to the CM must be done with the explicit consent of the CM via this API to ensure proper congestion behavior.
CMは、安定した輻輳回避や制御を実行する複数の同時ストリームの集合を可能にするエンド・システム・モジュールであり、アプリケーションが容易に支配ネットワーク条件に、その送信を適応させることができます。これは、すべてのアプリケーションおよびトランスポートプロトコル間で輻輳管理を統合します。これは、混雑パラメータ（使用可能な骨材とあたりストリーム帯域ごとの受信往復時間、等）を維持し、アプリケーションは、ネットワークの特性を学ぶ互いに、CMに共有渋滞情報を情報を渡すことを可能にするAPIをエクスポートそして、データ送信をスケジュール。 CMを使用する場合は、CMの対象となるすべてのデータ伝送は、適切な輻輳の動作を保証するために、このAPIを介してCMの明示的な同意を得て行われなければなりません。
Systems MAY choose to use CM, and if so they MUST follow this specification.
システムは、CMを使用することもできますし、もしそうなら、彼らは、この仕様に従わなければなりません。
This document focuses on applications and networks where the following conditions hold:
このドキュメントは、以下の条件を保持し、アプリケーションとネットワークに焦点を当てています。
1. Applications are well-behaved with their own independent per-byte or per-packet sequence number information, and use the CM API to update internal state in the CM.
1.アプリケーションは、独自の独立したバイト単位またはパケットシーケンス番号情報と行儀、およびCMで内部状態を更新するために、CMのAPIを使用しています。
2. Networks are best-effort without service discrimination or reservations. In particular, it does not address situations where different streams between the same pair of hosts traverse paths with differing characteristics.
2.ネットワークは、サービスの差別や予約なしのベストエフォートです。特に、ホストの同一の対の間の異なるストリームが異なる特性を有する経路を横切るような状況に対処していません。
The Congestion Manager framework can be extended to support applications that do not provide their own feedback and to differentially-served networks. These extensions will be addressed in later documents.
輻輳管理フレームワークは、独自のフィードバックを提供し、差動-務めネットワークへのないアプリケーションをサポートするように拡張することができます。これらの拡張機能は、後に文書で解決される予定です。
The CM is motivated by two main goals:
CMは、2つの主要な目標が動機とされています。
(i) Enable efficient multiplexing. Increasingly, the trend on the Internet is for unicast data senders (e.g., Web servers) to transmit heterogeneous types of data to receivers, ranging from unreliable real-time streaming content to reliable Web pages and applets. As a result, many logically different streams share the same path between sender and receiver. For the Internet to remain stable, each of these streams must incorporate control protocols that safely probe for spare bandwidth and react to congestion. Unfortunately, these concurrent streams typically compete with each other for network resources, rather than share them effectively. Furthermore, they do not learn from each other about the state of the network. Even if they each independently implement congestion control (e.g., a group of TCP connections each implementing the algorithms in [Jacobson88, Allman99]), the ensemble of streams tends to be more aggressive in the face of congestion than a single TCP connection implementing standard TCP congestion control and avoidance [Balakrishnan98].
（i）は、効率的な多重化を有効にします。ますます、インターネット上の傾向は、信頼できないリアルタイムのストリーミングコンテンツから信頼性の高いWebページおよびアプレットに至るまで、受信機へのデータの異質なタイプを送信するためにユニキャストデータ送信側（例えば、Webサーバ）のためです。結果として、多くの論理的に異なるストリームは、送信機と受信機との間の同じ経路を共有します。インターネットの安定を維持するためには、これらのストリームのそれぞれは、安全に予備の帯域幅をプローブと混雑に反応する制御プロトコルを組み込む必要があります。残念ながら、これらの同時ストリームは、一般的に効果的にそれらを共有するのではなく、ネットワークリソースのために互いに競合します。さらに、彼らは、ネットワークの状態について互いに学びません。彼らはそれぞれ独立して輻輳制御を実装する場合であっても（例えば、TCP接続のグループは[Jacobson88、Allman99]でアルゴリズムを実装それぞれ）、ストリームの集合は、標準的なTCPを実装する単一のTCP接続よりも混雑の面でより積極的になる傾向があります輻輳制御と回避[Balakrishnan98]。
(ii) Enable application adaptation to congestion. Increasingly, popular real-time streaming applications run over UDP using their own user-level transport protocols for good application performance, but in most cases today do not adapt or react properly to network congestion. By implementing a stable control algorithm and exposing an adaptation API, the CM enables easy application adaptation to congestion. Applications adapt the data they transmit to the current network conditions.
（ⅱ）輻輳へのアプリケーションの適応を有効にします。ますます、人気のリアルタイムストリーミングアプリケーションは、優れたアプリケーションのパフォーマンスのために、独自のユーザー・レベルのトランスポートプロトコルを使用して、UDP上で実行されますが、ほとんどのケースで、今日は適応していないか、ネットワークの輻輳に適切に反応します。安定した制御アルゴリズムを実装し、適応APIを露出することにより、CMは混雑への容易なアプリケーションの適応を可能にします。アプリケーションは、現在のネットワーク状態に送信データを適応させます。
The CM framework builds on recent work on TCP control block sharing [Touch97], integrated TCP congestion control (TCP-Int) [Balakrishnan98] and TCP sessions [Padmanabhan98]. [Touch97] advocates the sharing of some of the state in the TCP control block to improve transient transport performance and describes sharing across an ensemble of TCP connections. [Balakrishnan98],
CMフレームワークは、TCP制御ブロックを共有する[Touch97]、統合されたTCPの輻輳制御（TCP-INT）Balakrishnan98]とTCPセッション[Padmanabhan98]上の最近の研究に基づいています。 【Touch97】過渡輸送性能を向上させるTCP制御ブロック状態の一部の共有を主張し、TCP接続のアンサンブルを横切って共有記述する。 [Balakrishnan98]
[Padmanabhan98], and [Eggert00] describe several experiments that quantify the benefits of sharing congestion state, including improved stability in the face of congestion and better loss recovery. Integrating loss recovery across concurrent connections significantly improves performance because losses on one connection can be detected by noticing that later data sent on another connection has been received and acknowledged. The CM framework extends these ideas in two significant ways: (i) it extends congestion management to non-TCP streams, which are becoming increasingly common and often do not implement proper congestion management, and (ii) it provides an API for applications to adapt their transmissions to current network conditions. For an extended discussion of the motivation for the CM, its architecture, API, and algorithms, see [Balakrishnan99]; for a description of an implementation and performance results, see [Andersen00].
[Padmanabhan98]、および[Eggert00]渋滞と良好損失回復の面で改善された安定性を含む、輻輳状態を共有することの利点を定量化するいくつかの実験を記載します。一つの接続上の損失が別の接続で送信された後のデータを受信し、認識されていることに気付いすることによって検出することができるので、同時接続数全体の損失回復を統合することで、パフォーマンスが大幅に向上します。 CMのフレームワークは、二つの重要な方法でこれらのアイデアを拡張します（私は）それは、ますます一般的になってきているストリーム非TCPの輻輳管理を拡張し、多くの場合、適切な輻輳管理を実装していないと、（ii）それが適応するアプリケーションのためのAPIを提供します現在のネットワーク状態への送信。 CMの動機の拡張については、そのアーキテクチャ、API、およびアルゴリズムは、[Balakrishnan99]を参照します。実装および性能結果の説明については、[Andersen00]参照。
The resulting end-host protocol architecture at the sender is shown in Figure 1. The CM helps achieve network stability by implementing stable congestion avoidance and control algorithms that are "TCP-friendly" [Mahdavi98] based on algorithms described in [Allman99]. However, it does not attempt to enforce proper congestion behavior for all applications (but it does not preclude a policer on the host that performs this task). Note that while the policer at the end-host can use CM, the network has to be protected against compromises to the CM and the policer at the end hosts, a task that requires router machinery [Floyd99a]. We do not address this issue further in this document.
送信側で得られたエンドホスト・プロトコル・アーキテクチャは、CMは「TCPフレンドリー」[Mahdavi98] [Allman99]に記載のアルゴリズムに基づいている安定した輻輳回避と制御アルゴリズムを実装することによって、ネットワークの安定性を達成するのに役立つ、図1に示されています。しかし、それはすべてのアプリケーションのための適切な輻輳行動を強制しようとしません（それは、このタスクを実行するホスト上のポリサーを排除するものではありません）。エンドホストのポリサーがCMを使用することができながら、ネットワークは、CMとエンドホストにポリサー、[Floyd99a]ルータ機構を必要とするタスクに妥協に対して保護されなければならないことに留意されたいです。私たちは、この文書では、さらにこの問題に対処していません。
|--------| |--------| |--------| |--------| |--------------|
| HTTP | | FTP | | RTP 1 | | RTP 2 | | |
|--------| |--------| |--------| |--------| | |
| | | ^ | ^ | |
| | | | | | | Scheduler |
| | | | | | |---| | |
| | | |-------|--+->| | | |
| | | | | |<--| |
v v v v | | |--------------|
|--------| |--------| |-------------| | | ^
| TCP 1 | | TCP 2 | | UDP 1 | | A | |
|--------| |--------| |-------------| | | |
^ | ^ | | | | |--------------|
| | | | | | P |-->| |
| | | | | | | | |
|---|------+---|--------------|------->| | | Congestion |
| | | | I | | |
v v v | | | Controller |
|-----------------------------------| | | | |
| IP |-->| | | |
|-----------------------------------| | | |--------------|
|---|
Figure 1
図1
The key components of the CM framework are (i) the API, (ii) the congestion controller, and (iii) the scheduler. The API is (in part) motivated by the requirements of application-level framing (ALF) [Clark90], and is described in Section 4. The CM internals (Section 5) include a congestion controller (Section 5.1) and a scheduler to orchestrate data transmissions between concurrent streams in a macroflow (Section 5.2). The congestion controller adjusts the aggregate transmission rate between sender and receiver based on its estimate of congestion in the network. It obtains feedback about its past transmissions from applications themselves via the API. The scheduler apportions available bandwidth amongst the different streams within each macroflow and notifies applications when they are permitted to send data. This document focuses on well-behaved applications; a future one will describe the sender-receiver protocol and header formats that will handle applications that do not incorporate their own feedback to the CM.
CMフレームワークの主要なコンポーネントは、（i）API、（ii）の輻輳制御装置、および（iii）スケジューラです。 APIは、アプリケーションレベルのフレーミング（ALF）Clark90]の要件によって動機付け（部分的に）であり、輻輳制御装置（セクション5.1）と編成するスケジューラを含む第4 CMの内部（セクション5）に記載されていますmacroflowでの同時ストリーム間のデータ伝送（5.2節）。輻輳制御装置は、ネットワーク内の輻輳の推定値に基づいて送信者と受信者の間の集約伝送レートを調整します。これは、API経由でアプリケーション自体からその過去の送信に関するフィードバックを取得します。スケジューラは、各macroflow内の異なるストリームの間で利用可能な帯域幅を配分し、それらがデータを送信することが許可されたときにアプリケーションに通知します。この文書では、行儀のアプリケーションに焦点を当て、将来の1はCMに自分の意見を取り入れていないアプリケーションを処理する送信者、受信プロトコルとヘッダの形式を説明します。
By convention, the IETF does not treat Application Programming Interfaces as standards track. However, it is considered important to have the CM API and CM algorithm requirements in one coherent document. The following section on the CM API uses the terms MUST,
慣例により、IETFが標準化トラックとしてアプリケーション・プログラミング・インタフェースを扱いません。しかし、1つのコヒーレント文書のCMのAPIとCMアルゴリズム要件を持つことが重要であると考えられます。 CM APIの次のセクションでは、用語をしなければならない使用しています
SHOULD, etc., but the terms are meant to apply within the context of an implementation of the CM API. The section does not apply to congestion control implementations in general, only to those implementations offering the CM API.
など、必要がありますが、用語がCM APIの実装のコンテキスト内で適用することを意図しています。セクションは、CMのAPIを提供し、それらの実装に、一般的に輻輳制御の実装には適用されません。
Using the CM API, streams can determine their share of the available bandwidth, request and have their data transmissions scheduled, inform the CM about successful transmissions, and be informed when the CM's estimate of path bandwidth changes. Thus, the CM frees applications from having to maintain information about the state of congestion and available bandwidth along any path.
CMのAPIを使用して、ストリームが利用可能な帯域幅、リクエストのシェアを決定し、そのデータ伝送が予定さ持って、成功した送信についてのCMに通知し、通知することができる時にパス帯域変更のCMの推定。したがって、CMは、輻輳状態と任意のパスに沿って利用可能な帯域幅に関する情報を維持することからアプリケーションを解放します。
The function prototypes below follow standard C language convention. We emphasize that these API functions are abstract calls and conformant CM implementations may differ in specific details, as long as equivalent functionality is provided.
以下の関数のプロトタイプは、標準のC言語の規則に従ってください。我々は、これらのAPI関数が抽象コールと準拠のCMの実装は限り同等の機能が提供されるよう、具体的な詳細が異なる場合があることを強調します。
When a new stream is created by an application, it passes some information to the CM via the cm_open(stream_info) API call. Currently, stream_info consists of the following information: (i) the source IP address, (ii) the source port, (iii) the destination IP address, (iv) the destination port, and (v) the IP protocol number.
新しいストリームがアプリケーションによって作成されると、それはcm_open（stream_info）APIの呼び出しを介してCMにいくつかの情報を渡します。 （I）は、ソースIPアドレス、（ii）の送信元ポート、（III）、宛先IPアドレス、（IV）、宛先ポート、および（v）IPプロトコル番号：現在、stream_infoは、以下の情報から成ります。
1. Open: All applications MUST call cm_open(stream_info) before using the CM API. This returns a handle, cm_streamid, for the application to use for all further CM API invocations for that stream. If the returned cm_streamid is -1, then the cm_open() failed and that stream cannot use the CM.
1.：すべてのアプリケーションは、CMのAPIを使用する前に、cm_open（stream_info）を呼び出す必要があります。アプリケーションは、そのストリームのすべての更なるCMのAPI呼び出しに使用するためにこれは、ハンドル、cm_streamidを返します。返さcm_streamidが-1であれば、cm_open（）が失敗し、そのストリームは、CMを使用することはできません。
All other calls to the CM for a stream use the cm_streamid returned from the cm_open() call.
ストリームのCMへのその他のすべての呼び出しはcm_open（）呼び出しから返さcm_streamidを使用しています。
2. Close: When a stream terminates, the application SHOULD invoke cm_close(cm_streamid) to inform the CM about the termination of the stream.
2.閉じる：ストリームが終了すると、アプリケーションはストリームの終了についてのCMに通知するcm_close（cm_streamid）を呼び出す必要があります。
3. Packet size: cm_mtu(cm_streamid) returns the estimated PMTU of the path between sender and receiver. Internally, this information SHOULD be obtained via path MTU discovery [Mogul90]. It MAY be statically configured in the absence of such a mechanism.
3.パケットサイズ：cm_mtu（cm_streamid）は送信側と受信側の間のパスの推定PMTUを返します。内部的には、この情報はパスMTU探索[Mogul90]を介して得られるはずです。これは、静的に、そのようなメカニズムの不在で構成することができます。
The CM accommodates two types of adaptive senders, enabling applications to dynamically adapt their content based on prevailing network conditions, and supporting ALF-based applications.
CMは、動的にネットワークの状態を実勢、およびALFベースのアプリケーションをサポートするに基づいて、その内容を適応するアプリケーションを実現、適応送信者の2種類に対応しています。
1. Callback-based transmission. The callback-based transmission API puts the stream in firm control of deciding what to transmit at each point in time. To achieve this, the CM does not buffer any data; instead, it allows streams the opportunity to adapt to unexpected network changes at the last possible instant. Thus, this enables streams to "pull out" and repacketize data upon learning about any rate change, which is hard to do once the data has been buffered. The CM must implement a cm_request(i32 cm_streamid) call for streams wishing to send data in this style. After some time, depending on the rate, the CM MUST invoke a callback using cmapp_send(), which is a grant for the stream to send up to PMTU bytes. The callback-style API is the recommended choice for ALF-based streams. Note that cm_request() does not take the number of bytes or MTU-sized units as an argument; each call to cm_request() is an implicit request for sending up to PMTU bytes. The CM MAY provide an alternate interface, cm_request(int k). The cmapp_send callback for this request is granted the right to send up to k PMTU sized segments. Section 4.3 discusses the time duration for which the transmission grant is valid, while Section 5.2 describes how these requests are scheduled and callbacks made.
1.コールバックベースの伝送。コールバックベースの伝送APIは、各時点で送信するためにどのような決定をしっかりコントロールにストリームを置きます。これを達成するために、CMは、任意のデータをバッファリングしません。代わりに、それが最後の可能な瞬間に予期しないネットワークの変化に適応する機会をストリームできます。したがって、これは「引き出す」と、データがバッファリングされた後に行うのは難しいです任意のレートの変更、についての学習時にデータをrepacketizeするストリームできます。 CMはこのスタイルでデータを送信したいストリームのcm_request（I32のcm_streamid）呼び出しを実装する必要があります。しばらくすると、速度に応じて、CMは、PMTUのバイトまで送信するストリームに対するグラントである、）（cmapp_sendを使用してコールバックを呼び出す必要があります。コールバックスタイルのAPIは、ALF-ベースのストリームのためのお勧めの選択です。そのcm_requestに注意してください（）の引数としてバイト数またはMTUサイズの単位を取りません。 cm_requestする各呼び出しは（）PMTUバイトまで送るための暗黙的要求です。 CMは、代替インタフェース、cm_request（int型K）を提供することができます。この要求のcmapp_sendコールバックは、PMTUサイズのセグメントをk個まで送信する権利が付与されます。 5.2節は、これらの要求がスケジュールとコールバックが行われている方法を説明しながら、4.3節では、送信許可が有効である時間期間について説明します。
2. Synchronous-style. The above callback-based API accommodates a class of ALF streams that are "asynchronous." Asynchronous transmitters do not transmit based on a periodic clock, but do so triggered by asynchronous events like file reads or captured frames. On the other hand, there are many streams that are "synchronous" transmitters, which transmit periodically based on their own internal timers (e.g., an audio senders that sends at a constant sampling rate). While CM callbacks could be configured to periodically interrupt such transmitters, the transmit loop of such applications is less affected if they retain their original timer-based loop. In addition, it complicates the CM API to have a stream express the periodicity and granularity of its callbacks. Thus, the CM MUST export an API that allows such streams to be informed of changes in rates using the cmapp_update(u64 newrate, u32 srtt, u32 rttdev) callback function, where newrate is the new rate in bits per second for this stream, srtt is the current smoothed round trip time estimate in microseconds, and rttdev is the smoothed linear deviation in the round-trip time estimate calculated using the same algorithm as in TCP [Paxson00]. The newrate value reports an instantaneous rate calculated, for example, by taking the ratio of cwnd and srtt, and dividing by the fraction of that ratio allocated to the stream.
2.同期スタイル。上記のコールバックベースのAPIは、ALFストリームのクラス収納する「非同期」を非同期送信機は、周期クロックに基づいて送信することはありませんが、ファイルの読み取りまたはフレームをキャプチャのようなので、非同期イベントによってトリガありません。一方、定期的に（例えば、一定のサンプリングレートで送信する音声送信者）自分の内部タイマに基づいて送信「同期」送信機、多くのストリームが存在します。 CMのコールバックが定期的に、このような送信機を中断するように構成することができますが、彼らは元のタイマーベースのループを保持している場合、そのようなアプリケーションの送信ループはあまり影響を受けています。また、ストリームはそのコールバックの周期性や粒度を表現するために持っているCMのAPIを複雑にします。したがって、CMはSRTT、そのようなストリームはnewrateはこのストリームの秒当たりのビットで新たなレートでcmapp_update（U64のnewrate、U32のSRTT、U32のrttdev）コールバック関数を使用して、速度の変化を通知することを可能にするAPIをエクスポートする必要がありますマイクロ現在の平滑化往復時間推定値であり、rttdevはTCP [Paxson00]と同じアルゴリズムを用いて計算往復時間推定において平滑化線形偏差です。 newrate値は、例えば、CWNDおよびSRTTの比をとると、ストリームに割り当てられ、その比の分数で割ることによって、計算瞬間レートを報告します。
In response, the stream MUST adapt its packet size or change its timer interval to conform to (i.e., not exceed) the allowed rate. Of course, it may choose not to use all of this rate. Note that the CM is not on the data path of the actual transmission.
応答では、ストリームは、そのパケットのサイズを適合させるか、（すなわち、超えない）許容レートに適合するために、そのタイマー間隔を変更する必要があります。もちろん、それはこのレートのすべてを使用しないことも選択できます。 CMは、実際の送信のデータ・パス上にないことに留意されたいです。
To avoid unnecessary cmapp_update() callbacks that the application will only ignore, the CM MUST provide a cm_thresh(float rate_downthresh, float rate_upthresh, float rtt_downthresh, float rtt_upthresh) function that a stream can use at any stage in its execution. In response, the CM SHOULD invoke the callback only when the rate decreases to less than (rate_downthresh * lastrate) or increases to more than (rate_upthresh * lastrate), where lastrate is the rate last notified to the stream, or when the round-trip time changes correspondingly by the requisite thresholds. This information is used as a hint by the CM, in the sense the cmapp_update() can be called even if these conditions are not met.
）（不要cmapp_updateを避けるためには、アプリケーションがのみ無視することのコールバック、CMは流れがその実行中にいずれかの段階で使用することができますcm_thresh（フロートrate_downthresh、フロートrate_upthresh、フロートrtt_downthresh、フロートrtt_upthresh）機能を提供しなければなりません。これに応答して、CMは、速度がlastrateが最後のストリームに通知速度、又は場合往復である以上（rate_upthresh * lastrate）に（rate_downthresh * lastrate）未満又は増加に減少する場合にのみ、コールバックを呼び出す必要があります時間が必要なしきい値により相応に変化します。この情報は、意味でcmapp_update（）は、これらの条件が満たされていない場合でも呼び出すことができ、CMによってヒントとして使用されます。
The CM MUST implement a cm_query(i32 cm_streamid, u64* rate, u32* srtt, u32* rttdev) to allow an application to query the current CM state. This sets the rate variable to the current rate estimate in bits per second, the srtt variable to the current smoothed round-trip time estimate in microseconds, and rttdev to the mean linear deviation. If the CM does not have valid estimates for the macroflow, it fills in negative values for the rate, srtt, and rttdev.
CMは、現在のCMの状態を照会するためのアプリケーションを可能にするためにcm_query（rttdev I32のcm_streamid、U64の*率、U32 * SRTT、U32 *）を実装しなければなりません。これは、現在の平滑化往復時間マイクロ推定値、及び平均線偏差にrttdevにbps単位で現在のレート推定値に速度変数、SRTT変数を設定します。 CMはmacroflowの有効な見積もりを持っていない場合、それは率、SRTT、およびrttdev用負の値で埋めます。
Note that a stream can use more than one of the above transmission APIs at the same time. In particular, the knowledge of sustainable rate is useful for asynchronous streams as well as synchronous ones; e.g., an asynchronous Web server disseminating images using TCP may use cmapp_send() to schedule its transmissions and cmapp_update() to decide whether to send a low-resolution or high-resolution image. A TCP implementation using the CM is described in Section 6.1.1, where the benefit of the cm_request() callback API for TCP will become apparent.
ストリームが同時に上記伝送のAPIの複数を使用することができることに留意されたいです。具体的には、持続可能なレートの知識は、非同期ストリームならびに同期ものに有用です。例えば、TCPを使用してイメージを広める非同期Webサーバは、低解像度または高解像度の画像を送信するかどうかを決定する（）は、その送信及びcmapp_updateを（スケジュールする）cmapp_sendを使用することができます。 CMを使用してTCP実装は、TCPのためcm_request（）コールバックAPIの利点が明らかになるであろう6.1.1項に記載されています。
The reader will notice that the basic CM API does not provide an interface for buffered congestion-controlled transmissions. This is intentional, since this transmission mode can be implemented using the callback-based primitive. Section 6.1.2 describes how congestion-controlled UDP sockets may be implemented using the CM API.
読者は、基本的なCM APIは、バッファ輻輳制御伝送のためのインタフェースを提供していないことがわかります。この送信モードは、コールバック・ベースのプリミティブを使用して実施することができるので、これは、意図的です。セクション6.1.2は、輻輳制御のUDPソケットは、CM APIを使用して実施することができる方法を説明します。
When a stream receives feedback from receivers, it MUST use cm_update(i32 cm_streamid, u32 nrecd, u32 nlost, u8 lossmode, i32 rtt) to inform the CM about events such as congestion losses, successful receptions, type of loss (timeout event, Explicit Congestion Notification [Ramakrishnan99], etc.) and round-trip time samples. The nrecd parameter indicates how many bytes were successfully received by the receiver since the last cm_update call, while the nrecd parameter identifies how many bytes were received were lost during the same time period. The rtt value indicates the round-trip time measured during the transmission of these bytes. The rtt value must be set to -1 if no valid round-trip sample was obtained by the application. The lossmode parameter provides an indicator of how a loss was detected. A value of CM_NO_FEEDBACK indicates that the application has received no feedback for all its outstanding data, and is reporting this to the CM. For example, a TCP that has experienced a timeout would use this parameter to inform the CM of this. A value of CM_LOSS_FEEDBACK indicates that the application has experienced some loss, which it believes to be due to congestion, but not all outstanding data has been lost. For example, a TCP segment loss detected using duplicate (selective) acknowledgments or other data-driven techniques fits this category. A value of CM_EXPLICIT_CONGESTION indicates that the receiver echoed an explicit congestion notification message. Finally, a value of CM_NO_CONGESTION indicates that no congestion-related loss has occurred. The lossmode parameter MUST be reported as a bit-vector where the bits correspond to CM_NO_FEEDBACK, CM_LOSS_FEEDBACK, CM_EXPLICIT_CONGESTION, and CM_NO_CONGESTION. Note that over links (paths) that experience losses for reasons other than congestion, an application SHOULD inform the CM of losses, with the CM_NO_CONGESTION field set.
ストリームは、受信機からのフィードバックを受信すると、そのような渋滞損失、成功したレセプション、損失（タイムアウトイベントの種類、明示などのイベントについてのCMに通知するcm_update（I32のcm_streamid、U32のnrecd、U32のnlost、U8のlossmode、I32 RTT）を使用する必要があります輻輳通知[Ramakrishnan99]など）および往復時間サンプル。 nrecdパラメータが受信されたが、同じ期間中に失われたバイト数を識別しながらnrecdパラメータは、成功した最後のcm_updateの呼び出し以降に受信機で受信したバイト数を示します。 RTT値は、これらのバイトの送信中に測定された往復時間を示しています。有効な往復サンプルがアプリケーションによって得られなかった場合は、RTTの値が-1に設定する必要があります。 lossmodeパラメータは、損失が検出されたかの指標を提供します。 CM_NO_FEEDBACKの値は、アプリケーションがそのすべての未処理データのためのフィードバックを受けなかったことを示し、そしてCMにこれを報告しています。たとえば、タイムアウトを経験しているTCPは、このCMを知らせるために、このパラメータを使用します。 CM_LOSS_FEEDBACKの値は、アプリケーションが、それが輻輳によるものと信じているいくつかの損失を経験しているが、すべての未処理のデータが失われているではないことを示しています。例えば、重複（選択）肯定応答又は他のデータ駆動型の手法を用いて検出したTCPセグメント損失は、このカテゴリに適合する。 CM_EXPLICIT_CONGESTIONの値は、受信機が明示的輻輳通知メッセージをエコーすることを示しています。最後に、CM_NO_CONGESTIONの値が輻輳関連の損失が発生していないことを示しています。 lossmodeパラメータは、ビットがCM_NO_FEEDBACK、CM_LOSS_FEEDBACK、CM_EXPLICIT_CONGESTION、及びCM_NO_CONGESTIONに対応するビット・ベクトルとして報告しなければなりません。リンク（パス）輻輳以外の理由でその経験損失の上に、アプリケーションはCM_NO_CONGESTIONフィールドセットで、損失のCMに知らせるべきであることに注意してください。
cm_notify(i32 cm_streamid, u32 nsent) MUST be called when data is transmitted from the host (e.g., in the IP output routine) to inform the CM that nsent bytes were just transmitted on a given stream. This allows the CM to update its estimate of the number of outstanding bytes for the macroflow and for the stream.
データ（IP出力ルーチンにおいて、例えば、）ホストから送信されたときcm_notify（I32のcm_streamid、U32のnsent）はnsentバイトは単に指定されたストリーム上で送信されたCMに通知するために呼び出さなければなりません。これはCMがmacroflowため、ストリームのための未処理のバイト数の見積りを更新することができます。
A cmapp_send() grant from the CM to an application is valid only for an expiration time, equal to the larger of the round-trip time and an implementation-dependent threshold communicated as an argument to the cmapp_send() callback function. The application MUST NOT send data based on this callback after this time has expired. Furthermore, if the application decides not to send data after receiving this callback, it SHOULD call cm_notify(stream_info, 0) to allow the CM to permit other streams in the macroflow to transmit data. The CM congestion controller MUST be robust to applications forgetting to invoke cm_notify(stream_info, 0) correctly, or applications that crash or disappear after having made a cm_request() call.
アプリケーションへのCMからcmapp_send（）許可は、唯一の有効期限のためのラウンドトリップ時間の大きい方とcmapp_send（）コールバック関数への引数として通信実装依存の閾値に等しい有効です。この時間が経過した後、アプリケーションは、このコールバックに基づいてデータを送ってはいけません。アプリケーションはこのコールバックを受信した後にデータを送信しないことを決定した場合また、それは、CMがデータを送信するmacroflowの他のストリームを許可できるように（0、stream_info）cm_notifyを呼び出す必要があります。 CM輻輳制御装置が正常（0、stream_info）cm_notifyを呼び出すために忘れアプリケーション、またはcm_request（）呼び出しを行った後にクラッシュまたは消失アプリケーションに対して堅牢でなければなりません。
If applications wish to learn about per-stream available bandwidth and round-trip time, they can use the CM's cm_query(i32 cm_streamid, i64* rate, i32* srtt, i32* rttdev) call, which fills in the desired quantities. If the CM does not have valid estimates for the macroflow, it fills in negative values for the rate, srtt, and rttdev.
アプリケーションごとのストリーム利用可能な帯域幅とラウンドトリップ時間について学びたい場合は、それらが所望の量で埋めCMのcm_query（I32のcm_streamid、I64 *率、I32 * SRTT、I32 * rttdev）のコールを、使用することができます。 CMはmacroflowの有効な見積もりを持っていない場合、それは率、SRTT、およびrttdev用負の値で埋めます。
One of the decisions the CM needs to make is the granularity at which a macroflow is constructed, by deciding which streams belong to the same macroflow and share congestion information. The API provides two functions that allow applications to decide which of their streams ought to belong to the same macroflow.
CMを作るために必要な決定の一つは、同じmacroflowと共有渋滞情報に属しているストリームかを決めることでmacroflowが構築された粒度、です。 APIは、アプリケーションがそのストリームのどれが同じmacroflowに属しているべきかを決定するための2つの機能を提供します。
cm_getmacroflow(i32 cm_streamid) returns a unique i32 macroflow identifier. cm_setmacroflow(i32 cm_macroflowid, i32 cm_streamid) sets the macroflow of the stream cm_streamid to cm_macroflowid. If the cm_macroflowid that is passed to cm_setmacroflow() is -1, then a new macroflow is constructed and this is returned to the caller. Each call to cm_setmacroflow() overrides the previous macroflow association for the stream, should one exist.
cm_getmacroflow（I32のcm_streamid）が一意I32のmacroflow識別子を返します。 cm_setmacroflow（I32のcm_macroflowid、I32 cm_streamid）はcm_macroflowidするストリームcm_streamidのmacroflowを設定します。 （）cm_setmacroflowに渡されcm_macroflowidが-1の場合、新しいmacroflowが構築されており、これは、呼び出し元に返されます。 cm_setmacroflowへの各呼び出しは（）ストリームの以前macroflow関連付けをオーバーライドし、一方が存在するはずです。
The default suggested aggregation method is to aggregate by destination IP address; i.e., all streams to the same destination address are aggregated to a single macroflow by default. The cm_getmacroflow() and cm_setmacroflow() calls can then be used to change this as needed. We do note that there are some cases where this may not be optimal, even over best-effort networks. For example, when a group of receivers are behind a NAT device, the sender will see them all as one address. If the hosts behind the NAT are in fact connected over different bottleneck links, some of those hosts could see worse performance than before. It is possible to detect such hosts when using delay and loss estimates, although the specific mechanisms for doing so are beyond the scope of this document.
デフォルトでは集計方法は、宛先IPアドレスで集約することで示唆しました。すなわち、同一の宛先アドレスへのすべてのストリームは、デフォルトで単一macroflowに集約されています。その後、必要に応じてこれを変更するために使用することができcm_getmacroflow（）とcm_setmacroflowは（）を呼び出します。これはさえベストエフォート型のネットワーク上で、最適ではないかもしれないいくつかのケースがあることに注意してください。受信機のグループはNATデバイスの背後にあるとき、例えば、送信者が一つのアドレスとしてそれらすべてが表示されます。 NATの背後にあるホストが実際には別のボトルネックリンクを介して接続されている場合は、それらのホストの一部は前より悪いパフォーマンスを見ることができました。そうするための特定のメカニズムはこの文書の範囲外であるが、遅延と損失の推定値を使用する場合、このようなホストを検出することが可能です。
The objective of this interface is to set up sharing of groups not sharing policy of relative weights of streams in a macroflow. The latter requires the scheduler to provide an interface to set sharing policy. However, because we want to support many different schedulers (each of which may need different information to set policy), we do not specify a complete API to the scheduler (but see
このインタフェースの目的は、macroflow内のストリームの相対重みのポリシーを共有していないグループの共有を設定することです。後者は、共有ポリシーを設定するインターフェイスを提供するために、スケジューラを必要とします。我々は（ポリシーを設定するには、さまざまな情報が必要になることがあり、それぞれが）多くの異なるスケジューラをサポートしたいので、しかし、我々は、スケジューラへの完全なAPIを指定します（ただし、表示されていません
Section 5.2). A later guideline document is expected to describe a few simple schedulers (e.g., weighted round-robin, hierarchical scheduling) and the API they export to provide relative prioritization.
5.2節）。後の指針文書は、いくつかの簡単なスケジューラ（例えば、加重ラウンドロビン、階層的なスケジューリング）と、彼らは相対的な優先順位付けを提供するために、エクスポートするAPIを記述することが期待されます。
This section describes the internal components of the CM. It includes a Congestion Controller and a Scheduler, with well-defined, abstract interfaces exported by them.
このセクションでは、CMの内部コンポーネントについて説明します。それはそれらによってエクスポートされ、明確に定義され、抽象インタフェースと、輻輳制御装置およびスケジューラを含みます。
Associated with each macroflow is a congestion control algorithm; the collection of all these algorithms comprises the congestion controller of the CM. The control algorithm decides when and how much data can be transmitted by a macroflow. It uses application notifications (Section 4.3) from concurrent streams on the same macroflow to build up information about the congestion state of the network path used by the macroflow.
各macroflowに関連付けられた輻輳制御アルゴリズムです。すべてのこれらのアルゴリズムのコレクションは、CMの輻輳制御装置を備えています。制御アルゴリズムはmacroflowによって送信することができ、いつ、どのくらいのデータを決定します。それはmacroflowが使用するネットワーク経路の輻輳状態に関する情報を構築するために、同じmacroflowの同時ストリームからアプリケーション通知（4.3節）を使用しています。
The congestion controller MUST implement a "TCP-friendly" [Mahdavi98] congestion control algorithm. Several macroflows MAY (and indeed, often will) use the same congestion control algorithm but each macroflow maintains state about the network used by its streams.
輻輳制御装置は、「TCPフレンドリー」[Mahdavi98]輻輳制御アルゴリズムを実装しなければなりません。いくつかのmacroflowsは（そして実際、多くの場合します）同じ輻輳制御アルゴリズムを使用するかもしれませんが、各macroflowは、そのストリームが使用するネットワークについての状態を維持しています。
The congestion control module MUST implement the following abstract interfaces. We emphasize that these are not directly visible to applications; they are within the context of a macroflow, and are different from the CM API functions of Section 4.
輻輳制御モジュールは、以下の抽象インタフェースを実装しなければなりません。我々は、これらのアプリケーションに直接表示されていないことを強調します。彼らはmacroflowのコンテキスト内であり、そして第4のCM API関数とは異なります。
- void query(u64 *rate, u32 *srtt, u32 *rttdev): This function returns the estimated rate (in bits per second) and smoothed round trip time (in microseconds) for the macroflow.
- 空のクエリ（U64の*率、U32 * SRTT、U32 * rttdev）：この機能は、macroflowのための（マイクロ秒）（秒あたりのビット数）の推定率と平滑化往復時間を返します。
- void notify(u32 nsent): This function MUST be used to notify the congestion control module whenever data is sent by an application. The nsent parameter indicates the number of bytes just sent by the application.
- ボイド（U32のnsent）通知：この関数は、データがアプリケーションによって送信されるたびに、輻輳制御モジュールに通知するために使用されなければなりません。 nsentパラメータは、単にアプリケーションによって送信されたバイト数を示します。
- void update(u32 nsent, u32 nrecd, u32 rtt, u32 lossmode): This function is called whenever any of the CM streams associated with a macroflow identifies that data has reached the receiver or has been lost en route. The nrecd parameter indicates the number of bytes that have just arrived at the receiver. The nsent parameter is the sum of the number of bytes just received and the number of bytes identified as lost en route. The rtt parameter is the estimated round trip time in microseconds during the transfer. The lossmode parameter provides an indicator of how a loss was detected (section 4.3).
- ボイド更新（U32のnsent、U32のnrecd、U32 RTT、U32のlossmode）：macroflowに関連付けられたCMストリームのいずれかが、データが受信機に到達したか、途中で失われたことを識別するたびにこの関数が呼び出されます。 nrecdパラメータは、単に受信機に到着したバイト数を示します。 nsentパラメータは、ちょうど受信したバイト数と途中で失われたとして同定されたバイト数の合計です。 RTTパラメータは、転送中にマイクロ秒で推定往復時間です。 lossmodeパラメータは、損失は（セクション4.3）検出されたかの指標を提供します。
Although these interfaces are not visible to applications, the congestion controller MUST implement these abstract interfaces to provide for modular inter-operability with different separately-developed schedulers.
これらのインタフェースは、アプリケーションからは見えないが、輻輳制御装置は、異なる別々に開発スケジューラとモジュラー相互運用性を提供するために、これらの抽象インタフェースを実装しなければなりません。
The congestion control module MUST also call the associated scheduler's schedule function (section 5.2) when it believes that the current congestion state allows an MTU-sized packet to be sent.
それは現在の輻輳状態がMTUサイズのパケットが送信されることを可能にすると考えている場合、輻輳制御モジュールは、関連するスケジューラのスケジュール機能（セクション5.2）を呼び出す必要があります。
While it is the responsibility of the congestion control module to determine when and how much data can be transmitted, it is the responsibility of a macroflow's scheduler module to determine which of the streams should get the opportunity to transmit data.
それがいつ、どのくらいのデータを送信することができるかを決定するために輻輳制御モジュールの責任であるが、データを送信する機会を得るべきストリームのかを決定するためにmacroflowのスケジューラモジュールの責任です。
The Scheduler MUST implement the following interfaces:
スケジューラは、次のインタフェースを実装する必要があります。
- void schedule(u32 num_bytes): When the congestion control module determines that data can be sent, the schedule() routine MUST be called with no more than the number of bytes that can be sent. In turn, the scheduler MAY call the cmapp_send() function that CM applications must provide.
- ボイドスケジュール（U32のnum_bytesバイト）：輻輳制御モジュールは、データを送信することができると判断した場合、スケジュール（）ルーチンは、送信可能なバイト数を超えないで呼び出さなければなりません。ターンでは、スケジューラは、CMのアプリケーションが提供しなければならないcmapp_send（）関数を呼び出すことができます。
- float query_share(i32 cm_streamid): This call returns the described stream's share of the total bandwidth available to the macroflow. This call combined with the query call of the congestion controller provides the information to satisfy an application's cm_query() request.
- フロートquery_share（I32のcm_streamid）：この呼び出しはmacroflowが利用可能な総帯域幅の説明ストリームのシェアを返します。輻輳制御のクエリ呼び出しと組み合わさこの呼び出しは、アプリケーションのcm_query（）要求を満たすために情報を提供します。
- void notify(i32 cm_streamid, u32 nsent): This interface is used to notify the scheduler module whenever data is sent by a CM application. The nsent parameter indicates the number of bytes just sent by the application.
- ボイド（I32のcm_streamid、U32のnsent）通知：このインタフェースは、データがCMアプリケーションによって送信されたときにスケジューラモジュールに通知するために使用されます。 nsentパラメータは、単にアプリケーションによって送信されたバイト数を示します。
The Scheduler MAY implement many additional interfaces. As experience with CM schedulers increases, future documents may make additions and/or changes to some parts of the scheduler API.
スケジューラは、多くの追加のインタフェースを実装してもよいです。 CMスケジューラとの経験が増加すると、将来の文書は、スケジューラAPIのいくつかの部分に付加および/または変更を行うことがあります。
This section describes three possible uses of the CM API by
applications. We describe two asynchronous applications---an
implementation of a TCP sender and an implementation of congestion-
controlled UDP sockets, and a synchronous application---a streaming
audio server. More details of these applications and CM
implementation optimizations for efficient operation are described in
[Andersen00].
All applications that use the CM MUST incorporate feedback from the receiver. For example, it must periodically (typically once or twice per round trip time) determine how many of its packets arrived at the receiver. When the source gets this feedback, it MUST use cm_update() to inform the CM of this new information. This results in the CM updating ownd and may result in the CM changing its estimates and calling cmapp_update() of the streams of the macroflow.
CMを使用するすべてのアプリケーションは、受信機からのフィードバックを取り入れなければなりません。例えば、それは定期的に（通常は一度か二度往復時間あたり）受信機に到着したどのように多くのパケットのかを決定しなければなりません。ソースは、このフィードバックを取得すると、それはこの新しい情報のCMに通知するcm_update（）を使用しなければなりません。これはownd CM更新をもたらし、macroflowの流れのcmapp_updateを（）の推定値を変更し、呼び出しCMをもたらすことができます。
The protocols in this section are examples and suggestions for implementation, rather than requirements for any conformant implementation.
このセクションのプロトコルではなく、任意の準拠の実装のための要件よりも、実装のための例と提案しています。
A TCP implementation that uses CM should use the cmapp_send() callback API. TCP only identifies which data it should send upon the arrival of an acknowledgement or expiration of a timer. As a result, it requires tight control over when and if new data or retransmissions are sent.
CMはcmapp_sendを使用する必要があります（）コールバックAPIを使用してTCPの実装。 TCPは、それがタイマーの承認または満了の到着時に送信すべきデータを識別します。その結果、それは、新しいデータや再送が送られているかを厳密に制御する必要があります。
When TCP either connects to or accepts a connection from another host, it performs a cm_open() call to associate the TCP connection with a cm_streamid.
TCPが接続又は他のホストからの接続を受け入れるのいずれかの場合、それはcm_streamidとのTCP接続を関連付けるcm_open（）呼び出しを行います。
Once a connection is established, the CM is used to control the transmission of outgoing data. The CM eliminates the need for tracking and reacting to congestion in TCP, because the CM and its transmission API ensure proper congestion behavior. Loss recovery is still performed by TCP based on fast retransmissions and recovery as well as timeouts. In addition, TCP is also modified to have its own outstanding window (tcp_ownd) estimate. Whenever data segments are sent from its cmapp_send() callback, TCP updates its tcp_ownd value. The ownd variable is also updated after each cm_update() call. TCP also maintains a count of the number of outstanding segments (pkt_cnt). At any time, TCP can calculate the average packet size (avg_pkt_size) as tcp_ownd/pkt_cnt. The avg_pkt_size is used by TCP to help estimate the amount of outstanding data. Note that this is not needed if the SACK option is used on the connection, since this information is explicitly available.
接続が確立されると、CMは、発信データの送信を制御するために使用されます。 CMは、CMとその伝送APIが適切な混雑の動作を保証するため、追跡し、TCPの輻輳に反応する必要がなくなります。損失回復は依然、高速再送信と回復だけでなく、タイムアウトに基づいてTCPによって行われます。また、TCPはまた、独自の優れた窓（tcp_ownd）推定値を有するように修正されます。データセグメントは、そのcmapp_send（）コールバックから送信されるたびに、TCPは、そのtcp_ownd値を更新します。 ownd変数は、各cm_update（）呼び出しの後に更新されます。 TCPはまた、優れたセグメント（pkt_cnt）の数のカウントを維持します。いつでも、TCPはtcp_ownd / pkt_cntとして平均パケットサイズ（avg_pkt_size）を算出することができます。 avg_pkt_sizeは、優れたデータの量を推定するのに役立つTCPによって使用されます。 SACKオプションは、接続に使用されている場合、この情報が明示的に提供されていますので、これは、必要とされていないことに注意してください。
The TCP output routines are modified as follows:
次のようにTCP出力ルーチンが変更されます。
2. When application data is available. The TCP output routines perform all non-congestion checks (Nagle algorithm, receiver-advertised window check, etc). If these checks pass, the output routine queues the data and calls cm_request() for the stream.
2.アプリケーションデータが利用可能です。 TCP出力ルーチンは、すべての非輻輳チェック（Nagleアルゴリズム、受信機 - 広告ウィンドウのチェックなど）を実行します。これらのチェックは、出力がルーチンキューデータを渡し、ストリームのcm_request（）を呼び出した場合。
3. If incoming data or timers result in a loss being detected, the retransmission is also placed in a queue and cm_request() is called for the stream.
着信データ又はタイマーが検出される損失をもたらす3.場合、再送信は、キューに置かれ、cm_request（）ストリームのために呼び出されます。
4. The cmapp_send() callback for TCP is set to an output routine. If any retransmission is enqueued, the routine outputs the retransmission. Otherwise, the routine outputs as much new data as the TCP connection state allows. However, the cmapp_send() never sends more than a single segment per call. This routine arranges for the other output computations to be done, such as header and options computations.
4. TCP用cmapp_send（）コールバックは、出力ルーチンに設定されています。任意の再送信がエンキューされている場合は、ルーチンは再送を出力します。そうでなければ、多くの新しいデータなどの日常の出力は、TCP接続状態が許す限り。ただし、（）cmapp_sendは、コールごとに単一のセグメントよりも多くを送信することはありません。他の出力の計算のために、このルーチン並べは、ヘッダおよびオプションの計算として、行われます。
The IP output routine on the host calls cm_notify() when the packets are actually sent out. Because it does not know which cm_streamid is responsible for the packet, cm_notify() takes the stream_info as argument (see Section 4 for what the stream_info should contain). Because cm_notify() reports the IP payload size, TCP keeps track of the total header size and incorporates these updates.
パケットが実際に送信されたときに、ホスト上のIP出力ルーチンはcm_notify（）を呼び出します。それは、パケットを担当するcm_streamid知らないので、cm_notify（）（stream_infoが含まれている必要があります何のために第4節を参照）を引数としてstream_infoを取ります。 cm_notify（）はIPペイロードサイズを報告しているため、TCPは、全ヘッダサイズを追跡し、これらの更新プログラムが組み込まれています。
The TCP input routines are modified as follows:
次のようにTCP入力ルーチンが変更されます。
1. RTT estimation is done as normal using either timestamps or Karn's algorithm. Any rtt estimate that is generated is passed to CM via the cm_update call.
1. RTT推定は、タイムスタンプやカーンのアルゴリズムのいずれかを使用して通常通り行われます。生成された任意のRTT推定値はcm_updateの呼び出しを介してCMに渡されます。
2. All cwnd and slow start threshold (ssthresh) updates are removed.
2.すべてのcwndとスロースタート閾値は、（SSTHRESH）更新が削除されます。
3. Upon the arrival of an ack for new data, TCP computes the value of in_flight (the amount of data in flight) as snd_max-ack-1 (i.e., MAX Sequence Sent - Current Ack - 1). TCP then calls cm_update(streamid, tcp_ownd - in_flight, 0, CM_NO_CONGESTION, rtt).
新しいデータに対するACKが到着すると3は、TCPがsnd_max-ACK-1としてin_flightの値（飛行中のデータの量）を計算する（すなわち、MAXシーケンス送信 - 現在のAck - 1）。 TCPは、（ - in_flight、0、CM_NO_CONGESTION、RTT streamIDで、tcp_ownd）cm_updateを呼び出します。
4. Upon the arrival of a duplicate acknowledgement, TCP must check its dupack count (dup_acks) to determine its action. If dup_acks < 3, the TCP does nothing. If dup_acks == 3, TCP assumes that a packet was lost and that at least 3 packets arrived to generate these duplicate acks. Therefore, it calls cm_update(streamid, 4 * avg_pkt_size, 3 * avg_pkt_size, CM_LOSS_FEEDBACK, rtt). The average packet size is used since the acknowledgments do not indicate exactly how much data has reached the other end. Most TCP implementations interpret a duplicate ACK as an indication that a full MSS has reached its destination. Once a new ACK is received, these TCP sender implementations may resynchronize with TCP receiver. The CM API does not provide a mechanism for TCP to pass information from this resynchronization. Therefore, TCP can only infer the arrival of an avg_pkt_size amount of data from each duplicate ack. TCP also enqueues a retransmission of the lost segment and calls cm_request(). If dup_acks > 3, TCP assumes that a packet has reached the other end and caused this ack to be sent. As a result, it calls cm_update(streamid, avg_pkt_size, avg_pkt_size, CM_NO_CONGESTION, rtt).
重複確認応答が到着すると4、TCPはその作用を決定するためにそののdupack数（dup_acks）をチェックしなければなりません。 dup_acksは3 <場合、TCPは何もしません。 dup_acks == 3場合は、TCPパケットが失われたと、少なくとも3つのパケットがこれらの重複ACKを生成するために到着したことを想定しています。したがって、cm_update（streamIDで、4 *のavg_pkt_size、3 * avg_pkt_size、CM_LOSS_FEEDBACK、RTT）を呼び出します。確認応答がもう一方の端に到達している正確にどのくらいのデータを示すものではありませんので、平均パケットサイズが使用されています。ほとんどのTCP実装は、完全なMSSが宛先に到達したことを示すものとして、重複ACKを解釈します。新しいACKが受信されると、これらのTCPの送信側の実装は、TCP受信機と再同期します。 CM APIは、TCPは、この再同期からの情報を渡すためのメカニズムを提供していません。したがって、TCPは、各重複ACKからのデータのavg_pkt_size量の到着を推測することができます。 TCPはまた、失われたセグメントの再送をエンキューおよびcm_request（）を呼び出します。 dup_acks> 3ならば、TCPパケットがもう一方の端に到達し、このACKが送信される原因となっていることを前提としています。その結果、cm_update（streamIDで、avg_pkt_size、avg_pkt_size、CM_NO_CONGESTION、RTT）を呼び出します。
5. Upon the arrival of a partial acknowledgment (one that does not exceed the highest segment transmitted at the time the loss occurred, as defined in [Floyd99b]), TCP assumes that a packet was lost and that the retransmitted packet has reached the recipient. Therefore, it calls cm_update(streamid, 2 * avg_pkt_size, avg_pkt_size, CM_NO_CONGESTION, rtt). CM_NO_CONGESTION is used since the loss period has already been reported. TCP also enqueues a retransmission of the lost segment and calls cm_request().
部分的応答（[Floyd99b]で定義されるように、損失が発生した時点で送信最高セグメントを超えていないもの）の到着後5は、TCPパケットが失われたと仮定し、再送パケットが受信者に到達したことを。したがって、（streamIDで、2 * avg_pkt_size、avg_pkt_size、CM_NO_CONGESTION、RTT）cm_updateを呼び出します。損失期間がすでに報告されているので、CM_NO_CONGESTIONが使用されています。 TCPはまた、失われたセグメントの再送をエンキューおよびcm_request（）を呼び出します。
When the TCP retransmission timer expires, the sender identifies that a segment has been lost and calls cm_update(streamid, avg_pkt_size, 0, CM_NO_FEEDBACK, 0) to signify that no feedback has been received from the receiver and that one segment is sure to have "left the pipe." TCP also enqueues a retransmission of the lost segment and calls cm_request().
TCPの再送タイマが満了した場合、送信者は、セグメントが失われたことを識別し、cm_updateを呼び出します（streamIDで、avg_pkt_size、0、CM_NO_FEEDBACK、0）のフィードバックが受信機から受信しないと、1つのセグメントが "持っていると確信していることをされたことを意味しますパイプを残しました。」 TCPはまた、失われたセグメントの再送をエンキューおよびcm_request（）を呼び出します。
Congestion-controlled UDP is a useful CM application, which we describe in the context of Berkeley sockets [Stevens94]. They provide the same functionality as standard Berkeley UDP sockets, but instead of immediately sending the data from the kernel packet queue to lower layers for transmission, the buffered socket implementation makes calls to the API exported by the CM inside the kernel and gets callbacks from the CM. When a CM UDP socket is created, it is bound to a particular stream. Later, when data is added to the packet queue, cm_request() is called on the stream associated with the socket. When the CM schedules this stream for transmission, it calls udp_ccappsend() in the UDP module. This function transmits one MTU from the packet queue, and schedules the transmission of any remaining packets. The in-kernel implementation of the CM UDP API should not require any additional data copies and should support all standard UDP options. Modifying existing applications to use congestion-controlled UDP requires the implementation of a new socket option on the socket. To work correctly, the sender must obtain feedback about congestion. This can be done in at least two ways: (i) the UDP receiver application can provide feedback to the sender application, which will inform the CM of network conditions using cm_update(); (ii) the UDP receiver implementation can provide feedback to the sending UDP. Note that this latter alternative requires changes to the receiver's network stack and the sender UDP cannot assume that all receivers support this option without explicit negotiation.
輻輳制御UDPは、我々はバークレーソケット[Stevens94]の文脈で説明有用CMアプリケーションです。彼らは、標準のバークレーUDPソケットと同じ機能を提供しますが、代わりにすぐに送信するために下位層にカーネルのパケットキューからデータを送信する、バッファリングされたソケットの実装は、カーネル内部のCMによってエクスポートAPIへの呼び出しを行い、からのコールバックを取得しますCM。 CM UDPソケットが作成されると、それは特定のストリームにバインドされています。その後、データはパケットキュー、cm_request（に追加されたとき）は、ソケットに関連付けられたストリームに呼ばれています。 CMスケジュール伝送のためのこの流れは、それがUDPモジュール（）udp_ccappsend呼び出したとき。この関数は、1つのパケットキューからMTU、およびスケジュールの任意の残りのパケットの伝送を送信します。 CM UDPのAPIのカーネル内の実装は、追加のデータ・コピーを必要とすべきではないし、すべての標準的なUDPのオプションをサポートする必要があります。輻輳制御のUDPを使用する既存のアプリケーションを変更すると、ソケットに新しいソケットオプションを実装する必要があります。正しく機能するために、送信側は、輻輳に関するフィードバックを取得する必要があります。これは、少なくとも2つの方法で行うことができる：（I）UDP受信アプリケーションはcm_update（）を使用してネットワーク状態のCMを通知する送信側アプリケーションにフィードバックを提供することができます。 （ⅱ）UDP受信機の実装では、送信UDPにフィードバックを提供することができます。この後者の選択肢は、受信側のネットワークスタックへの変更を必要とし、送信者のUDPは、すべての受信機は、明示的な交渉せずにこのオプションをサポートしていると仮定することができないことに注意してください。
A typical audio application often has access to the sample in a multitude of data rates and qualities. The objective of the application is then to deliver the highest possible quality of audio (typically the highest data rate) its clients. The selection of which version of audio to transmit should be based on the current congestion state of the network. In addition, the source will want audio delivered to its users at a consistent sampling rate. As a result, it must send data a regular rate, minimizing delaying transmissions and reducing buffering before playback. To meet these requirements, this application can use the synchronous sender API (Section 4.2).
典型的なオーディオアプリケーションは、多くの場合、データレートと品質の多数のサンプルへのアクセス権を持っています。アプリケーションの目的は、オーディオ（通常は最高のデータレート）、クライアントの可能な限り最高の品質を提供するために、その後です。送信するオーディオのどのバージョンの選択は、ネットワークの現在の輻輳状態に基づくべきです。また、ソースは、オーディオが一貫性のあるサンプリングレートでそのユーザーに配信したいでしょう。その結果、遅延伝送を最小化し、再生する前にバッファリングを減らし、データを定期的にレートを送信する必要があります。これらの要件を満たすために、このアプリケーションは、同期送信者のAPI（4.2節）を使用することができます。
When the source first starts, it uses the cm_query() call to get an initial estimate of network bandwidth and delay. If some other streams on that macroflow have already been active, then it gets an initial estimate that is valid; otherwise, it gets negative values, which it ignores. It then chooses an encoding that does not exceed these estimates (or, in the case of an invalid estimate, uses application-specific initial values) and begins transmitting data. The application also implements the cmapp_update() callback. When the CM determines that network characteristics have changed, it calls the application's cmapp_update() function and passes it a new rate and round-trip time estimate. The application must change its choice of audio encoding to ensure that it does not exceed these new estimates.
ソースが最初に起動すると、ネットワーク帯域幅と遅延の初期推定値を取得するためにcm_query（）の呼び出しを使用しています。そのmacroflow上のいくつかの他のストリームがすでに活動している場合は、それが有効である初期推定値を取得します。そうでない場合、それは無視され、負の値を取得します。次に、これらの推定値を超えて（または、無効な推定の場合には、アプリケーション固有の初期値を使用して）、データの送信を開始しない符号化を選択します。また、アプリケーションはcmapp_update（）コールバックを実装しています。 CMは、ネットワークの特性が変化していると判断した場合、それはアプリケーションのcmapp_update（）関数を呼び出し、それに新しいレートおよびラウンドトリップ時間の推定値を渡します。アプリケーションは、これらの新しい推定値を超えないことを確実にするために、オーディオエンコーディングのその選択を変更する必要があります。
To illustrate the responsibilities of a congestion control module, the following describes some of the actions of a simple TCP-like congestion control module that implements Additive Increase Multiplicative Decrease congestion control (AIMD_CC):
輻輳制御モジュールの責任を説明するために、以下の添加剤は、乗算減少輻輳制御（AIMD_CC）を大きく実装し、単純なTCPのような輻輳制御モジュールのアクションのいくつかを説明します。
- query(): AIMD_CC returns the current congestion window (cwnd) divided by the smoothed rtt (srtt) as its bandwidth estimate. It returns the smoothed rtt estimate as srtt.
- クエリ（）：AIMD_CCは、その帯域幅推定値として平滑化RTT（SRTT）で割った現在の輻輳ウィンドウ（CWND）を返します。それはSRTTとして平滑化RTT推定値を返します。
- notify(): AIMD_CC adds the number of bytes sent to its outstanding data window (ownd).
- ）（通知：AIMD_CCは、その優れたデータ・ウィンドウ（ownd）に送信されたバイト数を加算します。
- update(): AIMD_CC subtracts nsent from ownd. If the value of rtt is non-zero, AIMD_CC updates srtt using the TCP srtt calculation. If the update indicates that data has been lost, AIMD_CC sets cwnd to 1 MTU if the loss_mode is CM_NO_FEEDBACK and to cwnd/2 (with a minimum of 1 MTU) if the loss_mode is CM_LOSS_FEEDBACK or CM_EXPLICIT_CONGESTION. AIMD_CC also sets its internal ssthresh variable to cwnd/2. If no loss had occurred, AIMD_CC mimics TCP slow start and linear growth modes. It increments cwnd by nsent when cwnd < ssthresh (bounded by a maximum of ssthresh-cwnd) and by nsent * MTU/cwnd when cwnd > ssthresh.
- アップデート（）：AIMD_CCはowndからnsentを減算します。 RTTの値がゼロでない場合、AIMD_CCの更新は、TCPのSRTT計算を使用してSRTT。更新は、データが失われたことを示す場合loss_modeがCM_NO_FEEDBACKとloss_modeがCM_LOSS_FEEDBACK又はCM_EXPLICIT_CONGESTIONである場合（1 MTUの最小値を有する）/ 2をcwndをする場合、AIMD_CC 1 MTUにCWNDを設定します。 AIMD_CCも/ 2をcwndをするためにその内部SSTHRESH変数を設定します。損失が発生しなかった場合は、AIMD_CC模倣はスロースタートと線形成長モードをTCP。 CWND <SSTHRESH（SSTHRESH-CWNDの最大値によって境界）とnsent * MTU / CWND CWNDによって> SSTHRESHときにnsentによってCWNDをインクリメントします。
- When cwnd or ownd are updated and indicate that at least one MTU may be transmitted, AIMD_CC calls the CM to schedule a transmission.
- CWND又はowndが更新され、少なくとも一つのMTUが送信されてもよいことを示している場合、AIMD_CC送信をスケジュールするためにCMを呼び出します。
To clarify the responsibilities of a scheduler module, the following describes some of the actions of a simple round robin scheduler module (RR_sched):
スケジューラモジュールの責任を明確にするため、次のように単純なラウンドロビンスケジューラモジュール（RR_sched）のアクションのいくつかを説明します。
- schedule(): RR_sched schedules as many streams as possible in round robin fashion.
- スケジュール（）：ラウンドロビン方式でできるだけ多くのストリームとしてRR_schedスケジュール。
- query_share(): RR_sched returns 1/(number of streams in macroflow).
- query_share（）：RR_schedリターン1 /（macroflowにおけるストリームの数）。
- notify(): RR_sched does nothing. Round robin scheduling is not affected by the amount of data sent.
- ）（通知：RR_schedは何もしません。ラウンドロビンスケジューリングは、送信されるデータの量に影響されません。
The CM provides many of the same services that the congestion control in TCP provides. As such, it is vulnerable to many of the same security problems. For example, incorrect reports of losses and transmissions will give the CM an inaccurate picture of the network's congestion state. By giving CM a high estimate of congestion, an attacker can degrade the performance observed by applications. For example, a stream on a host can arbitrarily slow down any other stream on the same macroflow, a form of denial of service.
CMは、TCPの輻輳制御を提供し、同じサービスの多くを提供します。このように、それは同じセキュリティ問題の多くに対して脆弱です。例えば、損失およびトランスミッションの間違った報告書は、CMに、ネットワークの輻輳状態の不正確な画像が得られます。 CMに混雑の高い推定値を与えることにより、攻撃者は、アプリケーションによって観察された性能を劣化させることができます。例えば、ホスト上のストリームを任意同じmacroflow、サービスの拒否の形で他の流れを遅くすることができます。
The more dangerous form of attack occurs when an application gives the CM a low estimate of congestion. This would cause CM to be overly aggressive and allow data to be sent much more quickly than sound congestion control policies would allow.
アプリケーションがCMに混雑の低い評価を与えたときに、攻撃のより危険な形で発生します。これはCMが過度に積極的で、データができるようになる音輻輳制御ポリシーよりもはるかに迅速に送ることができるようになります。
[Touch97] describes a number of the security problems that arise with congestion information sharing. An additional vulnerability (not covered by [Touch97])) occurs because applications have access through the CM API to control shared state that will affect other applications on the same computer. For instance, a poorly designed, possibly a compromised, or intentionally malicious UDP application could misuse cm_update() to cause starvation and/or too-aggressive behavior of others in the macroflow.
【Touch97】渋滞情報共有で生じるセキュリティ問題の数を記載しています。アプリケーションが同じコンピュータ上の他のアプリケーションに影響を与える共有状態を制御するためにCM APIを介してアクセスを持っているので、追加の脆弱性は、（[Touch97]でカバーされない））が発生します。例えば、不十分な可能性が損なわれ、あるいは意図的に悪意のあるUDPアプリケーションが飢餓および/またはmacroflowにおける他のあまり、積極的な行動を起こすことcm_updateを（）誤用可能性があり、設計されています。
[Allman99] Allman, M. and Paxson, V., "TCP Congestion Control", RFC 2581, April 1999.
[Allman99]オールマン、M.とパクソン、V.、 "TCP輻輳制御"、RFC 2581、1999年4月。
[Andersen00] Balakrishnan, H., System Support for Bandwidth Management and Content Adaptation in Internet Applications, Proc. 4th Symp. on Operating Systems Design and Implementation, San Diego, CA, October 2000. Available from http://nms.lcs.mit.edu/papers/cm-osdi2000.html
[Andersen00]バラクリシュナン、H.、帯域幅の管理およびインターネットアプリケーションにおけるコンテンツ適応のためのシステムサポート、PROC。第四SYMP。 http://nms.lcs.mit.edu/papers/cm-osdi2000.htmlから利用されているオペレーティングシステムの設計と実装、サンディエゴ、CA、2000年10月に
[Balakrishnan98] Balakrishnan, H., Padmanabhan, V., Seshan, S., Stemm, M., and Katz, R., "TCP Behavior of a Busy Web Server: Analysis and Improvements," Proc. IEEE INFOCOM, San Francisco, CA, March 1998.
【Balakrishnan98】バラクリシュナン、H.、Padmanabhan、V.、Seshan、S.、Stemm、M.、およびカッツ、R.、 "ビジーWebサーバのTCP挙動：分析と改善、" PROC。 IEEE INFOCOM、サンフランシスコ、CA、1998年3月。
[Balakrishnan99] Balakrishnan, H., Rahul, H., and Seshan, S., "An Integrated Congestion Management Architecture for Internet Hosts," Proc. ACM SIGCOMM, Cambridge, MA, September 1999.
[Balakrishnan99]バラクリシュナン、H.、ラーフル、H.、およびSeshan、S.、 "インターネットホストのための統合された輻輳管理アーキテクチャ、" PROC。 ACM SIGCOMM、ケンブリッジ、MA、1999年9月。
[Bradner96] Bradner, S., "The Internet Standards Process ---
Revision 3", BCP 9, RFC 2026, October 1996.
[Bradner97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[Bradner97]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[Clark90] Clark, D. and Tennenhouse, D., "Architectural Consideration for a New Generation of Protocols", Proc. ACM SIGCOMM, Philadelphia, PA, September 1990.
[Clark90]クラーク、D.とTennenhouse、D.、 "プロトコルの新世代のための建築配慮"、PROC。 ACM SIGCOMM、フィラデルフィア、PA、1990年9月。
[Eggert00] Eggert, L., Heidemann, J., and Touch, J., "Effects of Ensemble TCP," ACM Computer Comm. Review, January 2000.
[Eggert00]エッゲルト、L.、Heidemann、J.、およびタッチ、J.、ACMコンピュータCommの "アンサンブルTCP、の影響"。レビュー、2000年1月。
[Floyd99a] Floyd, S. and Fall, K.," Promoting the Use of End-to-End Congestion Control in the Internet," IEEE/ACM Trans. on Networking, 7(4), August 1999, pp. 458-472.
[Floyd99a]フロイド、S.と秋、K.、「インターネットにおけるエンドツーエンドの輻輳制御の利用促進、」IEEE / ACMトランス。ネットワーク上の、7（4）、1999年8月、頁458から472まで。
[Floyd99b] Floyd, S. and T. Henderson,"The New Reno Modification to TCP's Fast Recovery Algorithm," RFC 2582, April 1999.
[Floyd99b]フロイド、S.とT.ヘンダーソン、 "TCPの高速リカバリアルゴリズムに新しいリノ変更、" RFC 2582、1999年4月。
[Jacobson88] Jacobson, V., "Congestion Avoidance and Control," Proc. ACM SIGCOMM, Stanford, CA, August 1988.
[Jacobson88]ジェーコブソン、V.、 "輻輳回避とコントロール、" PROC。 ACM SIGCOMM、スタンフォード大学、カリフォルニア州、1988年8月。
[Mahdavi98] Mahdavi, J. and Floyd, S., "The TCP Friendly Website," http://www.psc.edu/networking/tcp_friendly.html
【Mahdavi98] Mahdavi、J.及びフロイド、S.、 "TCPフレンドリーなウェブサイト、" http://www.psc.edu/networking/tcp_friendly.html
[Mogul90] Mogul, J. and S. Deering, "Path MTU Discovery," RFC 1191, November 1990.
【Mogul90】モーグル、J.およびS.デアリング、 "パスMTUディスカバリ" RFC 1191、1990年11月。
[Padmanabhan98] Padmanabhan, V., "Addressing the Challenges of Web Data Transport," PhD thesis, Univ. of California, Berkeley, December 1998.
[Padmanabhan98] Padmanabhan、V.、 "Webデータ交通の課題に取り組む、" 博士論文、大学。カリフォルニア大学バークレー校、1998年12月の。
[Paxson00] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[Paxson00]パクソン、V.とM.オールマン、 "コンピューティングTCPの再送信タイマー"、RFC 2988、2000年11月。
[Postel81] Postel, J., Editor, "Transmission Control Protocol", STD 7, RFC 793, September 1981.
【Postel81]ポステル、J.、エディタ、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[Ramakrishnan99] Ramakrishnan, K. and Floyd, S., "A Proposal to Add Explicit Congestion Notification (ECN) to IP," RFC 2481, January 1999.
[Ramakrishnan99]ラマクリシュナン、K.とフロイド、S.、 "IPへの明示的輻輳通知（ECN）を追加するための提案、" RFC 2481、1999年1月。
[Stevens94] Stevens, W., TCP/IP Illustrated, Volume 1. Addison-Wesley, Reading, MA, 1994.
[Stevens94]スティーブンス、W.、TCP / IPイラスト、1巻アディソン・ウェズリー、読書、MA、1994。
[Touch97] Touch, J., "TCP Control Block Interdependence", RFC 2140, April 1997.
[Touch97]タッチ、J.、 "TCP制御ブロック相互依存"、RFC 2140、1997年4月。
We thank David Andersen, Deepak Bansal, and Dorothy Curtis for their work on the CM design and implementation. We thank Vern Paxson for his detailed comments, feedback, and patience, and Sally Floyd, Mark Handley, and Steven McCanne for useful feedback on the CM architecture. Allison Mankin and Joe Touch provided several useful comments on previous drafts of this document.
私たちは、CMの設計と実装上の自分の仕事のためにデビッド・アンデルセン、ディーパック・バンソール、およびドロシーカーティスに感謝します。私たちは、彼の詳細なコメント、フィードバック、そして忍耐のためのバーン・パクソンに感謝し、CMのアーキテクチャ上の有用なフィードバックのためのサリー・フロイド、マーク・ハンドリー、およびスティーブンMcCanne。アリソンマンキンとジョー・タッチは、この文書の前の草稿にいくつかの有用なコメントを提供しました。
Hari Balakrishnan Laboratory for Computer Science 200 Technology Square Massachusetts Institute of Technology Cambridge, MA 02139
テクノロジーケンブリッジ、MA 02139のコンピュータサイエンス200の技術スクエアマサチューセッツ工科大学のためのハリ・バラクリシュナン研究所
EMail: hari@lcs.mit.edu Web: http://nms.lcs.mit.edu/~hari/
メールアドレス：hari@lcs.mit.eduウェブ：http://nms.lcs.mit.edu/~hari/
Srinivasan Seshan School of Computer Science Carnegie Mellon University 5000 Forbes Ave. Pittsburgh, PA 15213
コンピュータサイエンスカーネギーメロン大学のスリニバサン・セシャン学校5000フォーブスアベニュー。ピッツバーグ、PA 15213
EMail: srini@cmu.edu Web: http://www.cs.cmu.edu/~srini/
メールアドレス：srini@cmu.eduウェブ：http://www.cs.cmu.edu/~srini/
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。