[要約] RFC 3124は、ネットワークの混雑を管理するためのアルゴリズムであり、要約すると以下のようになります。1. 目的: ネットワークの混雑を効果的に管理するためのアルゴリズムを提供する。 2. 要約: RFC 3124は、ネットワークの混雑を制御するためのアルゴリズムであり、効果的なリソース管理を目指している。 3. 目的: ネットワークの混雑を最小限に抑え、パフォーマンスを最適化するためのアルゴリズムを提供する。
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.
Copyright（c）The Internet Society（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.
（ii）アプリケーションがネットワークの混雑に簡単に適応できるようにする。
1. Conventions used in this document:
1. このドキュメントで使用される規則：
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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
マクロフロー
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対応ストリームのグループ。現在、さまざまなレシーバーに運命づけられたストリームは、異なるマクロフローに属しています。同じレシーバーに運命づけられたストリームは、異なるマクロフローに属している場合があります。渋滞マネージャーが使用されている場合、同一のうっ血行動を経験し、同じ渋滞制御アルゴリズムを使用するストリームは、同じマクロフローに属する必要があります。
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を使用するソフトウェアモジュール。これには、Webサーバーやオーディオ/ビデオサーバーなどのユーザーレベルのアプリケーション、およびCMを輻輳制御に使用するTCP [Postel81]などの型プロトコルが含まれます。
WELL-BEHAVED 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)
パス最大トランスミッションユニット（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)
傑出した窓（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)
初期ウィンドウ（IW）
The size of the sender's congestion window at the beginning of a macroflow.
マクロフローの先頭にある送信者の混雑ウィンドウのサイズ。
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.
署名されていない64ビットには「U64」、符号なしの32ビットには「U32」、符号なしの16ビットには「U16」、署名されていない8ビットには「U8」、署名された32ビットでは「I32」、「I16」には「U8」を使用します。署名された16ビット量の場合、IEEEフローティングポイント値の「フロート」。タイプ「void」は、呼び出しから返品値が予想されないことを示すために使用されます。ポインターは、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は、輻輳パラメーター（利用可能な集計およびストリームごとの帯域幅、レシーバーごとの往復時間など）を維持し、アプリケーションがネットワーク特性について学習し、情報をCMに渡すことを可能にするAPIをエクスポートし、互いの混合情報を共有できるようにします。、およびデータ送信をスケジュールします。このドキュメントは、独自の独立したバイトまたはパケットごとのシーケンス番号情報を備えたアプリケーションと輸送プロトコルに焦点を当てており、受信機プロトコルスタックの変更は必要ありません。ただし、受信アプリケーションは、受信したパケットと損失に関する送信アプリケーションにフィードバックを提供する必要があり、後者はCM APIを使用してCM状態を更新することが期待されています。このドキュメントは、予約やサービスの差別化を伴うネットワークには対応していません。
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 APIを使用してCMの内部状態を更新します。
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サーバーなど）がレシーバーにレシーバーに送信することです。その結果、多くの論理的に異なるストリームは、送信者と受信機の間で同じパスを共有しています。インターネットが安定したままであるためには、これらの各ストリームには、予備の帯域幅のために安全にプローブし、うっ血に反応する制御プロトコルを組み込む必要があります。残念ながら、これらの同時のストリームは通常、効果的に共有するのではなく、ネットワークリソースと互いに競合します。さらに、彼らはネットワークの状態について互いに学びません。彼らがそれぞれ独立して輻輳制御を実装していたとしても（たとえば、それぞれ[jacobson88、allman99]でアルゴリズムを実装する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.
（ii）輻輳に対するアプリケーションの適応を有効にする。人気のあるリアルタイムストリーミングアプリケーションは、適切なアプリケーションパフォーマンスのために独自のユーザーレベルのトランスポートプロトコルを使用して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フレームワークは、これらのアイデアを2つの重要な方法で拡張します。（i）混雑管理を非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.
送信者の結果として得られるエンドホストプロトコルアーキテクチャを図1に示します。CMは、[Allman99]に記載されているアルゴリズムに基づいて「TCPフレンドリー」[MAHDAVI98]である安定した混雑回避および制御アルゴリズムを実装することにより、ネットワークの安定性を実現するのに役立ちます。ただし、すべてのアプリケーションの適切な輻輳行動を実施しようとはしません（ただし、このタスクを実行するホストのポリサーを排除するものではありません）。エンドホストのポリサーはCMを使用できますが、ネットワークは、ルーター機械[Floyd99a]を必要とするタスクであるCMおよびEndホストのポリサーに対する妥協から保護する必要があることに注意してください。このドキュメントでは、この問題にこれ以上対処しません。
|--------| |--------| |--------| |--------| |--------------|
| 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]の要件によって動機付けられており、セクション4で説明されています。マクロフローの同時ストリーム間のデータ送信（セクション5.2）。混雑コントローラーは、ネットワーク内の渋滞の推定に基づいて、送信者と受信機の間の総送信速度を調整します。APIを介して、アプリケーション自体からの過去の送信に関するフィードバックを取得します。スケジューラapportionsは、各マクロフロー内のさまざまなストリーム間で帯域幅を利用でき、データの送信が許可されている場合にアプリケーションに通知します。このドキュメントは、行儀の良いアプリケーションに焦点を当てています。将来のものでは、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, 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.
慣習により、IETFはアプリケーションプログラミングインターフェイスを標準の追跡として扱いません。ただし、1つのコヒーレントドキュメントにCM APIおよびCMアルゴリズムの要件を持つことが重要であると考えられています。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に成功した送信について通知し、PATH帯域幅の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関数は抽象的な呼び出しであり、同等の機能が提供されている限り、特定の詳細が適切に異なる場合があることを強調します。
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に渡します。現在、Stream_Infoは次の情報で構成されています。（i）ソースIPアドレス、（ii）ソースポート、（iii）宛先IPアドレス、（iv）宛先ポート、および（v）IPプロトコル番号。
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_CLOSE（CM_STREAMID）を呼び出してCMにストリームの終了について通知する必要があります。
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を返します。内部的には、この情報はPath 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は2種類の適応送信者に対応し、アプリケーションが一般的なネットワーク条件に基づいてコンテンツを動的に適応させることができ、ALFベースのアプリケーションをサポートします。
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はデータをバッファリングしません。代わりに、可能な限り最後に予期しないネットワークの変更に適応する機会をストリーミングできます。したがって、これにより、ストリームは、あらゆるレートの変更について学習すると、データを「引き出し」、データを再パケット化できます。CMは、このスタイルでデータを送信したいストリームにCM_REQUEST（I32 CM_STREAMID）の呼び出しを実装する必要があります。しばらくして、レートに応じて、CMはCMAPP_SEND（）を使用してコールバックを呼び出す必要があります。これは、PMTUバイトに送信するストリームの助成金です。コールバックスタイルのAPIは、ALFベースのストリームに推奨される選択肢です。CM_REQUEST（）は、引数としてバイトまたはMTUサイズのユニットの数を取得しないことに注意してください。CM_REQUEST（）への各呼び出しは、PMTUバイトを送信するための暗黙のリクエストです。CMは、代替インターフェイスCM_REQUEST（INT K）を提供する場合があります。このリクエストのCMAPP_SENDコールバックは、K PMTUサイズのセグメントに送信する権利が付与されます。セクション4.3では、送信助成金が有効な期間について説明し、セクション5.2では、これらの要求がどのようにスケジュールされ、コールバックが行われたかについて説明します。
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は、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（float reate_downthresh、float_upthresh、float rtt_downthresh、float rtt_upthresh）関数を提供する必要があります。 これに応じて、CMは、レートが（rate_downthresh * lastrate）よりも低い場合、またはラストレートがストリームに最後に通知されるレートである場合、または往復の場合（rate_upthresh * 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_Query（I32 CM_STREAMID、U64*レート、U32* SRTT、U32* RTTDEV）を実装して、アプリケーションが現在のCM状態をクエリできるようにする必要があります。これにより、レート変数は1秒あたりのビットで現在のレート推定値に設定され、SRTT変数はマイクロ秒単位での現在の滑らかな往復時間推定値に、RTTDEVは平均線形偏差になります。CMがマクロフローの有効な推定値を持っていない場合、レート、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_send（）を使用してTransmissionsとcmapp_update（）をスケジュールして、低解像度画像か高解像度画像を送信するかを決定する場合があります。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では、CM APIを使用して輻輳制御UDPソケットをどのように実装するかについて説明します。
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_UPDATE（I32 CM_STREAMID、U32 NRECD、U32 NLOST、U8 LOSSMODE、I32 RTT）を使用する必要があります。混雑通知[Ramakrishnan99]など）および往復時間サンプル。NRECDパラメーターは、最後のCM_UPDATEコール以降、受信機によって正常に受信されたバイトの数を示しますが、NRECDパラメーターは、同じ期間に失われたバイト数が失われたバイト数を識別します。RTT値は、これらのバイトの透過中に測定された往復時間を示します。アプリケーションによって有効な往復サンプルが取得されなかった場合、RTT値を-1に設定する必要があります。損失モードパラメーターは、損失がどのように検出されたかの指標を提供します。CM_NO_Feedbackの値は、アプリケーションがすべての未解決のデータに対してフィードバックを受け取っていないことを示しており、これをCMに報告しています。たとえば、タイムアウトを経験したTCPは、このパラメーターを使用してCMにこれを通知します。CM_LOSS_FEEDBACKの値は、アプリケーションがいくつかの損失を経験していることを示しています。たとえば、重複（選択的）謝辞またはその他のデータ駆動型手法を使用して検出されたTCPセグメントの損失は、このカテゴリに適合します。CM_EXPLICIT_CONGESTIONの値は、受信者が明示的な輻輳通知メッセージをエコーしたことを示しています。最後に、CM_NO_CONGESTIONの値は、混雑関連の損失が発生していないことを示しています。損失モードパラメーターは、BITがCM_NO_FEEDBACK、CM_LOSS_FEEDBACK、CM_EXPLICIT_CONGESTION、およびCM_NO_CONGESTIONに対応するビットベクトルとして報告する必要があります。混雑以外の理由で損失を経験するリンク（PATHS）に注意してください。アプリケーションは、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.
CM_NOTIFY（I32 CM_STREAMID、U32 NSENT）は、データがホストから送信された場合（例：IP出力ルーチン）、NSENTバイトが特定のストリームに送信されたことを通知するために呼び出さなければなりません。これにより、CMは、マクロフローとストリームの未解決のバイトの数の推定値を更新できます。
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からCMからアプリケーションへのCMAPP_SEND（）助成金は、有効期限が切れている場合にのみ有効であり、往復時間の大きい方とCMAPP_SEND（）コールバック関数への引数として伝達される実装依存のしきい値に等しい。この時間が期限切れになった後、アプリケーションはこのコールバックに基づいてデータを送信してはなりません。さらに、アプリケーションがこのコールバックを受信した後にデータを送信しないことを決定した場合、CM_Notify（Stream_Info、0）を呼び出して、CMがMacroflow内の他のストリームにデータを送信できるようにする必要があります。CMの混雑コントローラーは、CM_Notify（Stream_Info、0）を正しく呼び出すのを忘れるアプリケーションに対して堅牢でなければなりません。
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がマクロフローの有効な推定値を持っていない場合、レート、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が行う必要がある決定の1つは、同じマクロフローに属するストリームと混雑情報を共有することを決定することにより、マクロフローが構築される粒度です。APIは、アプリケーションが同じマクロフローに属するべきストリームを決定できるようにする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マクロフロー識別子を返します。CM_SETMACROFLOW（I32 CM_MACROFLOWID、I32 CM_STREAMID）は、CM_STREAMIDのマクロフローをCM_MACROFLOWIDに設定します。CM_SETMACROFLOW（）に渡されるCM_MACROFLOWIDが-1である場合、新しいMacroflowが構築され、これが発信者に返されます。CM_SETMACROFLOW（）への各呼び出しは、存在した場合、以前のMacroflow Association for the Streamをオーバーライドします。
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アドレスによって集約することです。つまり、同じ宛先アドレスへのすべてのストリームは、デフォルトで単一のマクロフローに集約されます。CM_GETMACROFLOW（）およびCM_SETMACROFLOW（）呼び出しは、必要に応じてこれを変更するために使用できます。これが最適ではなく、最高のエフォルトネットワークよりも最適ではない場合がある場合があることに注意してください。たとえば、受信機のグループがNATデバイスの背後にある場合、送信者はそれらをすべて1つのアドレスと見なします。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 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.
このインターフェイスの目的は、マクロフロー内のストリームの相対的な重みのポリシーを共有しないグループの共有をセットアップすることです。後者では、スケジューラが共有ポリシーを設定するためのインターフェイスを提供する必要があります。ただし、多くの異なるスケジューラをサポートしたいため（それぞれがポリシーを設定するには異なる情報が必要になる場合があります）、スケジューラに完全なAPIを指定しません（ただし、セクション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.
各マクロフローに関連付けられているのは、輻輳制御アルゴリズムです。これらすべてのアルゴリズムのコレクションは、CMの輻輳コントローラーで構成されています。コントロールアルゴリズムは、マクロフローによっていつ、どのくらいのデータを送信できるかを決定します。同じマクロフローの同時ストリームからのアプリケーション通知（セクション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]輻輳制御アルゴリズムを実装する必要があります。いくつかのマクロフローは、同じ渋滞制御アルゴリズムを使用する可能性があります（実際、実際にはしばしば）が、各マクロフロウは、そのストリームで使用されるネットワークについて状態を維持しています。
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.
輻輳制御モジュールは、次の抽象インターフェイスを実装する必要があります。これらはアプリケーションに直接表示されないことを強調します。それらはマクロフローのコンテキスト内にあり、セクション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.
- void query（u64 *rate、u32 *srtt、u32 *rttdev）：この関数は、マクロフローの推定レート（1秒あたりのビット）を返し、滑らかな往復時間（マイクロ秒）を返します。
- 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.
- void notify（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).
- void Update（U32 NSENT、U32 NRECD、U32 RTT、U32 LOSSMODE）：この関数は、マクロフローに関連付けられたCMストリームのいずれかがデータが受信機に到達したか、途中で失われたことを識別するたびに呼び出されます。NRECDパラメーターは、レシーバーに到達したばかりのバイト数を示します。NSENTパラメーターは、受信したバイト数と、途中で失われたものとして識別されるバイト数の合計です。RTTパラメーターは、転送中のマイクロ秒単位での推定往復時間です。損失モードパラメーターは、損失がどのように検出されたかの指標を提供します（セクション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.
渋滞制御モジュールの責任は、いつ、どのくらいのデータを送信できるかを決定する責任ですが、マクロフローのスケジューラモジュールの責任は、どのストリームがデータを送信する機会を得るべきかを判断する責任です。
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.
- voidスケジュール（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.
- float query_share（i32 cm_streamid）：この呼び出しは、マクロフロウが利用できる合計帯域幅の記述されたストリームのシェアを返します。この呼び出しは、輻輳コントローラーのクエリコールと組み合わせて、アプリケーションの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.
- void Notify（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].
このセクションでは、アプリケーションによるCM APIの3つの可能な用途について説明します。TCP送信者の実装と輻輳制御UDPソケットの実装と同期アプリケーションの実装---ストリーミングオーディオサーバーについて、2つの非同期アプリケーションについて説明します。これらのアプリケーションの詳細と、効率的な動作のためのCM実装最適化については、[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を使用するすべてのアプリケーションは、受信機からフィードバックを組み込む必要があります。たとえば、定期的に（通常、往復時間ごとに1回または2回）、受信機に到着したパケットの数を決定する必要があります。ソースがこのフィードバックを取得した場合、CM_UPDATE（）を使用してこの新しい情報をCMに通知する必要があります。これにより、CMがOwnDを更新し、CMが推定値を変更し、MacroflowのストリームのCMAPP_UPDATE（）を呼び出す可能性があります。
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を使用するTCP実装では、cmapp_send（）callback apiを使用する必要があります。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_OPEN（）コールを実行して、TCP接続をCM_STREAMIDに関連付けます。
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（）callbackから送信されるたびに、TCPはTCP_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出力ルーチンは次のように変更されます。
1. All congestion window (cwnd) checks are removed.
1. すべての輻輳ウィンドウ（CWND）チェックが削除されます。
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を引数として取得します（stream_infoが含まれるものについてはセクション4を参照）。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).
3. 新しいデータにACKが到着すると、TCPはsnd_max -ack -1（つまり、最大シーケンスが送信される最大シーケンス-current ack -1）としてin_flightの値（飛行中のデータの量）を計算します。 TCPはCM_UPDATE（Streamid、TCP_OWND -IN_FLIGHT、0、CM_NO_CONGESTION、RTT）を呼び出します。
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().
5. 部分的な認識が到着すると（[Floyd99b]で定義されているように、損失が発生した時点で送信された最高セグメントを超えないもの）、TCPはパケットが失われ、再送信パケットが受信者に到達したと想定しています。したがって、cm_update（streamid、2 * avg_pkt_size、avg_pkt_size、cm_no_congestion、rtt）を呼び出します。損失期間がすでに報告されているため、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は有用なCMアプリケーションであり、これはバークレーソケット[Stevens94]のコンテキストで説明しています。それらは標準のバークレーUDPソケットと同じ機能を提供しますが、カーネルパケットキューからデータをすぐに送信するためにレイヤーを下げます。CM。CM UDPソケットが作成されると、特定のストリームにバインドされます。後で、データがパケットキューに追加されると、cm_request（）がソケットに関連付けられたストリームで呼び出されます。CMがこのストリームを送信するためにスケジュールすると、UDPモジュールでudp_ccappsend（）を呼び出します。この関数は、パケットキューから1つのMTUを送信し、残りのパケットの送信をスケジュールします。CM UDP APIの型型実装は、追加のデータコピーを必要とせず、すべての標準UDPオプションをサポートする必要があります。既存のアプリケーションを変更して輻輳制御UDPを使用するには、ソケットに新しいソケットオプションを実装する必要があります。正しく動作するには、送信者は輻輳に関するフィードバックを取得する必要があります。これは、少なくとも2つの方法で行うことができます。（i）UDPレシーバーアプリケーションは、cm_update（）を使用してネットワーク条件をCMに通知する送信者アプリケーションにフィードバックを提供できます。（ii）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（）コールを使用して、ネットワーク帯域幅と遅延の初期見積もりを取得します。そのマクロフロウの他のいくつかのストリームがすでにアクティブである場合、有効な初期推定が取得されます。それ以外の場合、それは負の値を取得し、それは無視します。次に、これらの推定値を超えないエンコーディングを選択します（または、無効な推定の場合、アプリケーション固有の初期値を使用します）。データの送信を開始します。アプリケーションは、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):
輻輳制御モジュールの責任を説明するために、以下は、加法の増加を実装する単純な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.
- query（）：aimd_ccは、現在の輻輳ウィンドウ（CWND）を帯域幅の見積もりとして平滑化されたRTT（SRTT）で割ったものを返します。スムーズなRTT推定値をSRTTとして返します。
- notify(): AIMD_CC adds the number of bytes sent to its outstanding data window (ownd).
- notify（）：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.
- update（）：aimd_ccはnsentを所有者から減算します。RTTの値がゼロ以外の場合、AIMD_CCはTCP SRTT計算を使用してSRTTを更新します。更新がデータが失われたことを示している場合、ress_modeがcm_no_feedbackである場合、aimd_ccはcm_no_feedbackである場合、cwndを1 mtuに設定し、loss_loss_feedbackまたはcm_explicit_congestionの場合はcwnd/2（最低1 mtu）に設定します。AIMD_CCは、内部SSTHRESH変数をCWND/2に設定します。損失が発生しなかった場合、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が更新され、少なくとも1つの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/（マクロフローのストリーム数）を返します。
- notify(): RR_sched does nothing. Round robin scheduling is not affected by the amount of data sent.
- notify（）：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に輻輳の高い推定値を与えることにより、攻撃者はアプリケーションによって観察されたパフォーマンスを分解できます。たとえば、ホストのストリームは、同じマクロフローの他のストリーム、サービス拒否の形式を任意に遅くすることができます。
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アプリケーションは、CM_UPDATE（）を誤用して、マクロフローの他の人の飢starおよび/または攻撃的な行動を引き起こす可能性があります。
[Allman99] Allman, M. and Paxson, V., "TCP Congestion Control", RFC 2581, April 1999.
[Allman99] Allman、M。and Paxson、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] Balakrishnan、H.、インターネットアプリケーションにおける帯域幅管理とコンテンツ適応のシステムサポート、Proc。4th Symp。2000年10月、カリフォルニア州サンディエゴのオペレーティングシステムの設計と実装について。http：//nms.lcs.mit.edu/papers/cm-osdi2000.htmlから入手できます。
[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] Balakrishnan、H.、Padmanabhan、V.、Seshan、S.、Stemm、M。、およびKatz、R。、「忙しいWebサーバーのTCP挙動：分析と改善」、Proc。IEEE Infocom、カリフォルニア州サンフランシスコ、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] Balakrishnan、H.、Rahul、H。、およびSeshan、S。、「インターネットホスト向けの統合渋滞管理アーキテクチャ」、Proc。ACM SIGCOMM、ケンブリッジ、マサチューセッツ州、1999年9月。
[Bradner96] Bradner, S., "The Internet Standards Process --- Revision 3", BCP 9, RFC 2026, October 1996.
[Bradner96] Bradner、S。、「インターネット標準プロセス---改訂3」、BCP 9、RFC 2026、1996年10月。
[Bradner97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[Bradner97] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Clark、D。およびTennenhouse、D。、「新世代のプロトコルに対する建築的考察」、Proc。ACM Sigcomm、Philadelphia、PA、1990年9月。
[Eggert00] Eggert, L., Heidemann, J., and Touch, J., "Effects of Ensemble TCP," ACM Computer Comm. Review, January 2000.
[Eggert00] Eggert、L.、Heidemann、J。、およびTouch、J。、「アンサンブルTCPの効果」、ACM Computer Comm。レビュー、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] Floyd、S。and Fall、K。、「インターネットでのエンドツーエンドの混雑制御の使用を促進する」、IEEE/ACM Trans。ネットワーキング、7（4）、1999年8月、pp。458-472。
[Floyd99b] Floyd, S. and T. Henderson,"The New Reno Modification to TCP's Fast Recovery Algorithm," RFC 2582, April 1999.
[Floyd99b] Floyd、S。およびT. Henderson、「TCPの高速回復アルゴリズムへの新しいリノ変更」、RFC 2582、1999年4月。
[Jacobson88] Jacobson, V., "Congestion Avoidance and Control," Proc. ACM SIGCOMM, Stanford, CA, August 1988.
[Jacobson88] Jacobson、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。およびFloyd、S。、「TCPフレンドリーなWebサイト」、http：//www.psc.edu/networking/tcp_friendly.html
[Mogul90] Mogul, J. and S. Deering, "Path MTU Discovery," RFC 1191, November 1990.
[Mogul90] Mogul、J。およびS. Deering、「Path MTU Discovery」、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] Paxson、V。およびM. Allman、「TCPの再送信タイマーのコンピューティング」、RFC 2988、2000年11月。
[Postel81] Postel, J., Editor, "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[Postel81] Postel、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] Ramakrishnan、K。およびFloyd、S。、「IPに明示的な混雑通知（ECN）を追加する提案」、RFC 2481、1999年1月。
[Stevens94] Stevens, W., TCP/IP Illustrated, Volume 1. Addison-Wesley, Reading, MA, 1994.
[Stevens94] Stevens、W.、TCP/IP Illustrated、Volume 1. Addison-Wesley、Reading、MA、1994。
[Touch97] Touch, J., "TCP Control Block Interdependence", RFC 2140, April 1997.
[Touch97] Touch、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.
David Andersen、Deepak Bansal、およびDorothy Curtisに、CMの設計と実装に関する作業に感謝します。Vern Paxsonの詳細なコメント、フィードバック、Patience、Sally Floyd、Mark Handley、Steven McCanneのCMアーキテクチャに関する有用なフィードバックをくれたことに感謝します。アリソン・マンキンとジョー・タッチは、この文書の以前のドラフトについていくつかの有用なコメントを提供しました。
Hari Balakrishnan Laboratory for Computer Science 200 Technology Square Massachusetts Institute of Technology Cambridge, MA 02139
ハリバラクリシュナン研究所コンピュータサイエンス200テクノロジースクエアマサチューセッツテクノロジーケンブリッジ、マサチューセッツ州02139
EMail: hari@lcs.mit.edu
Web: http://nms.lcs.mit.edu/~hari/
Srinivasan Seshan School of Computer Science Carnegie Mellon University 5000 Forbes Ave. Pittsburgh, PA 15213
スリニバサン・セシャン・スクール・オブ・コンピューター・サイエンス・カーネギー・メロン大学5000フォーブス・アベニュー・ピッツバーグ、ペンシルベニア州15213
EMail: srini@cmu.edu
Web: http://www.cs.cmu.edu/~srini/
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。