RFC3124 日本語訳
3124 The Congestion Manager. H. Balakrishnan, S. Seshan. June 2001. (Format: TXT=53591 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group H. Balakrishnan
Request for Comments: 3124 MIT LCS
Category: Standards Track S. Seshan
CMU
June 2001
Balakrishnanがコメントのために要求するワーキンググループH.をネットワークでつないでください: 3124年のMIT LCSカテゴリ: 標準化過程S.Seshan米カーネギーメロン大学2001年6月
The Congestion Manager
混雑マネージャ
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
Abstract
要約
This document describes the Congestion Manager (CM), an end-system module that:
このドキュメントはCongestionマネージャ(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)が、同じ受信機に運命づけられていて、同じ混雑の特性を共有しているa送付者からの複数の同時発生のストリームのアンサンブルが適切な輻輳回避とコントロールを実行するのを可能にする。
(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].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは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タイプ、トランスポート・プロトコル、ソース、および目的地トランスポート層を共有するパケットのすべて、グループは数を移植します。
Balakrishnan, et. al. Standards Track [Page 1] RFC 3124 The Congestion Manager June 2001
et Balakrishnan、アル。 規格は混雑マネージャ2001年6月にRFC3124を追跡します[1ページ]。
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に属すかもしれません。 Congestionマネージャが使用中であるときに、同じ混雑の振舞いを経験して、同じ輻輳制御アルゴリズムSHOULDを使用するストリームが同じ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を使用する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.
macroflowの始めの送付者の混雑ウィンドウのサイズ。
Balakrishnan, et. al. Standards Track [Page 2] RFC 3124 The Congestion Manager June 2001
et Balakrishnan、アル。 規格は混雑マネージャ2001年6月にRFC3124を追跡します[2ページ]。
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"、「署名している16ビットの量のためのi16"、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関数が「抽象的な」呼び出しであり、conformant CM実装が特定の実装の詳細において異なるかもしれないと強調します。
2. Introduction
2. 序論
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は、混雑パラメタ(利用可能な集合と1ストリームあたりの帯域幅、1受信機あたりの往復の回など)を維持して、アプリケーションがネットワークの特性に関して学んで、情報をCMに通過して、混雑情報を互いと共有して、データ伝送の計画をするのを可能にするAPIをエクスポートします。 このドキュメントがそれら自身の独立者でアプリケーションとトランスポート・プロトコルに焦点を合わせる、-、バイトか1パケットあたりの一連番号情報、受信機プロトコル・スタックへの変更を必要としません。 しかしながら、受信アプリケーションは容認されたパケットと損失に関する送付アプリケーションにフィードバックを前提としなければなりません、そして、後者が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は、複数の同時発生のストリームのアンサンブルが安定した輻輳回避とコントロールを実行するのを可能にする終わりシステム・モジュールであり、アプリケーションが容易に行き渡っているネットワーク状態に彼らのトランスミッションを適合させるのを許容します。 それはすべてのアプリケーションとトランスポート・プロトコルの向こう側にふくそう管理を統合します。 それは、混雑パラメタ(利用可能な集合と1ストリームあたりの帯域幅、1受信機あたりの往復の回など)を維持して、アプリケーションがネットワークの特性に関して学んで、情報をCMに通過して、混雑情報を互いと共有して、データ伝送の計画をするのを可能にするAPIをエクスポートします。 CMが使用されているとき、このAPIを通してCMの明白な同意で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:
このドキュメントは以下の条件が成立するアプリケーションとネットワークに焦点を合わせます:
Balakrishnan, et. al. Standards Track [Page 3] RFC 3124 The Congestion Manager June 2001
et Balakrishnan、アル。 規格は混雑マネージャ2001年6月にRFC3124を追跡します[3ページ]。
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.
それら自身のフィードバックを提供しないサポートアプリケーションと、そして、特異的に役立たれたネットワークにCongestionマネージャフレームワークを広げることができます。 これらの拡大は後のドキュメントで扱われるでしょう。
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) 効率的なマルチプレクシングを可能にしてください。 ますます、インターネットの傾向はユニキャストデータ送付者(例えば、ウェブサーバ)が異種のタイプに関するデータを受信機に送ることです、あてにならないリアルタイムのストリーミングの内容から信頼できるウェブページとアプレットまで及んで。 その結果、多くの論理的に異なったストリームが送付者と受信機の間の同じ経路を共有します。インターネットが安定した状態を保つために、それぞれのこれらのストリームは安全に予備帯域幅に調べて、混雑に反応する制御プロトコルを取り入れなければなりません。 残念ながら、これらの同時発生のストリームはネットワーク資源のために有効にそれらを共有するよりむしろ互いと通常競争します。 その上、彼らはネットワークの事情に関して互いから学びません。 彼らが、輻輳制御が(例えば、それぞれ[Jacobson88、Allman99]のアルゴリズムを実装するTCP接続のグループ)であるとそれぞれ独自に実装しても、ストリームのアンサンブルは、混雑に直面して標準の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.
(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],
TCP制御ブロック共有での近作の上のCMフレームワーク体格[Touch97]、統合TCP輻輳制御(TCP-Int)[Balakrishnan98]、およびTCPセッション[Padmanabhan98]。 [Touch97]は、一時的な輸送性能を向上させるためにTCP制御ブロックで何らかの状態の共有について提唱して、TCP接続のアンサンブルの向こう側に共有すると説明します。 [Balakrishnan98]
Balakrishnan, et. al. Standards Track [Page 4] RFC 3124 The Congestion Manager June 2001
et Balakrishnan、アル。 規格は混雑マネージャ2001年6月にRFC3124を追跡します[4ページ]。
[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]は混雑状態を共有する利益を定量化するいくつかの実験について説明します、混雑と、より良い損失回復に直面して改良された安定性を含んでいて。 同時接続の向こう側に損失回復を統合すると、性能は、後のデータが、別の接続が受けられて、承諾されたのを転送したのに気付くことによって1つの接続の損失を検出できるので、かなり向上します。 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]であるアルゴリズムであると実装することによってネットワークの安定性を達成するのを助けます。 しかしながら、それは、すべてのアプリケーションのための適切な混雑の振舞いを実施するのを試みません(それはこのタスクを実行するホストの上でpolicerを排除しません)。 終わりのホストのpolicerがCMを使用できる間ネットワークが終わりのホストにCMとpolicerへの感染に対して保護されなければならないことに注意してください、ルータ機械[Floyd99a]を必要とするタスク。 私たちはさらに本書ではこの問題を扱いません。
Balakrishnan, et. al. Standards Track [Page 5] RFC 3124 The Congestion Manager June 2001
et Balakrishnan、アル。 規格は混雑マネージャ2001年6月にRFC3124を追跡します[5ページ]。
|--------| |--------| |--------| |--------| |--------------|
| 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 |-->| | | |
|-----------------------------------| | | |--------------|
|---|
|--------| |--------| |--------| |--------| |--------------| | HTTP| | FTP| | RTP1| | RTP2| | | |--------| |--------| |--------| |--------| | | | | | ^ | ^ | | | | | | | | | スケジューラ| | | | | | | |---| | | | | | |-------|--+->|、|、|、|、|、|、|、|、| | <--、|、| v対vに| | |--------------| |--------| |--------| |-------------| | | ^ | TCP1| | TCP2| | UDP1| | A| | |--------| |--------| |-------------| | | | ^ | ^ | | | | |--------------| | | | | | | P| -->、|、|、|、|、|、|、|、|、|、|、| |---|------+---|、-、-、-、-、-、-、-、-、-、-、-、-、--、|、-、-、-、-、-、--、>|、|、| 混雑| | | | | I| | | v vに対して| | | コントローラ| |-----------------------------------| | | | | | 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で説明されます。 CMインターナル(セクション5)は、macroflow(セクション5.2)の同時発生のストリームの間のデータ伝送を調整するために混雑コントローラ(セクション5.1)とスケジューラを含んでいます。 混雑コントローラはネットワークにおける、混雑の見積りに基づく送付者と受信機の間の集合通信速度を調整します。 それはAPIを通してアプリケーション自体から過去のトランスミッションに関するフィードバックを得ます。 スケジューラは、各macroflowの中の異なったストリームの中で利用可能な帯域幅を分配して、データを送ることが許可されているとき、アプリケーションに通知します。 このドキュメントは行儀のよいアプリケーションに焦点を合わせます。 将来のものはそれら自身のフィードバックをCMに取り入れないアプリケーションを扱う送付者受信機プロトコルとヘッダー形式について説明するでしょう。
3. CM API
3. CM API
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は標準化過程としてApplication Programming Interfacesを扱いません。 しかしながら、それは1通の論理的なドキュメントのCM APIとCMアルゴリズム要件を持つために重要であると考えられます。 用語がそうしなければならないCM API用途の以下のセクション
Balakrishnan, et. al. Standards Track [Page 6] RFC 3124 The Congestion Manager June 2001
et Balakrishnan、アル。 規格は混雑マネージャ2001年6月にRFC3124を追跡します[6ページ]。
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.
しかし、SHOULD、など、用語は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関数が抽象的な呼び出しであり、conformant 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_戸外(ストリーム_インフォメーション)のAPI呼び出しで何らかの情報をCMに通過します。 現在、ストリーム_インフォメーションは以下の情報から成ります: (i) (v) ソースIPアドレス、(ii)ソースポート、(iii)送付先IPアドレス、(iv)仕向港、およびIPは数について議定書の中で述べます。
3.1 State maintenance
3.1 州のメインテナンス
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_戸外(ストリーム_インフォメーション)と呼ばなければなりません。 これはそのストリームのためのさらなるすべてのCM API実施に使用するアプリケーションのためにハンドル、cm_streamidを返します。 返されたcm_streamidが-1であるなら、cm_戸外()は失敗しました、そして、そのストリームはCMを使用できません。
All other calls to the CM for a stream use the cm_streamid
returned from the cm_open() call.
cm_streamidがcm_戸外()から返したストリーム使用のためのCMへの他のすべての呼び出しが呼びます。
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. 以下を閉じてください。 ストリームが終わると、アプリケーションSHOULDは、ストリームの終了に関するCMを知らせるためにcm_閉鎖(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を返す、内部的である、この情報SHOULD、経路MTU探索[Mogul90]で、得てください。 それはそのようなメカニズムがないとき静的に構成されるかもしれません。
Balakrishnan, et. al. Standards Track [Page 7] RFC 3124 The Congestion Manager June 2001
et Balakrishnan、アル。 規格は混雑マネージャ2001年6月にRFC3124を追跡します[7ページ]。
3.2 Data transmission
3.2データ伝送
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は少しのデータもバッファリングしません。 代わりに、それは最後の可能な瞬間に予期していなかったネットワーク変化に順応する機会をストリームに許容します。 したがって、これは、ストリームがどんなレート変化に関しても学ぶことに関するデータを「引き抜い」て、repacketizeするのを可能にします。データがいったんバッファリングされると、変化はしにくいです。 CMはストリームのためのこのスタイルでデータを送りたがっているcm_要求(i32cm_streamid)呼び出しを実装しなければなりません。 cmapp_を使用して、CMがレートによって、コールバックを呼び出さなければならないいつかの時の後に、()を送ってください。(()はストリームがPMTUバイトまで送る交付金です)。 コールバックスタイルAPIはALFベースのストリームのためのお勧めの選択です。cm_要求()が議論としてバイトかMTUサイズの単位の数をみなさないことに注意してください。 PMTUバイトまで発信するのを求めてcm_要求()への各呼び出しは暗黙の要求です。 CMは代替のインタフェース、cm_要求(int k)を提供するかもしれません。 _がコールバックを送るcmappは、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はそれがTCP[Paxson00]のようにレートにおける変化がnewrateがbpsで、このストリームの新しいレートであり、srttがマイクロセカンドの現在の平坦な周遊旅行時間見積りであり、rttdevが同じアルゴリズムを使用することで計算された往復の時間見積りにおいて平坦な直線的な逸脱であるcmapp_アップデート(u64 newrate、u32 srtt、u32 rttdev)コールバック機能を使用するのにおいて知識があるのをそのようなストリームを許容するAPIをエクスポートしなければなりません。 例えば、newrate値は、瞬時に起こっているレートが計算されているとcwndとsrttの比率を取って、ストリームに割り当てられたその比率の部分に応じて分割することによって、報告します。
Balakrishnan, et. al. Standards Track [Page 8] RFC 3124 The Congestion Manager June 2001
et Balakrishnan、アル。 規格は混雑マネージャ2001年6月にRFC3124を追跡します[8ページ]。
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_アップデート()コールバックを避けるために、CMはストリームがどんな段階でも実行に使用できるcm_脱穀(レート_downthreshを浮かべてください、浮遊物のレート_upthresh、浮遊物のrtt_downthresh、浮遊物のrtt_upthresh)機能を提供しなければなりません。 応答では、レートが単にlastrateが最後にストリームに通知されたレートである(レート_upthresh*lastrate)以上への(レート_downthresh*lastrate)か増加以下と減少するか、または往復の時間が必要な敷居で対応する変化するとき、CM SHOULDはコールバックを呼び出します。 この情報はヒントとしてCMによって使用されます、これらの条件が満たされないでもcmapp_アップデート()を呼ぶことができる意味で。
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_質問(i32cm_streamid、u64*を評価します、u32*srtt、u32*rttdev)を実装しなければなりません。 これはbpsにおける成り行き相場見積り、マイクロセカンドの現在の平坦な往復の時間見積りへのsrtt変数、および平均である直線的な逸脱へのrttdevにレート変数を設定します。 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の1つ以上を使用できることに注意してください。 持続可能なレートに関する知識は特に、同期ものと同様に非同期なストリームの役に立ちます。 例えば、TCPを使用することでイメージを広める非同期なウェブサーバは_がそのトランスミッションとcmapp_アップデート()が、低い解像度か解像度の高い像を送るかどうか決める計画をするように()を送るcmappを使用するかもしれません。 CMを使用するTCP実装はセクション6.1.1で説明されます。そこでは、TCPのためのcm_要求()コールバックAPIの利益が明らかになるでしょう。
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を使用することでどう実装されるかもしれないかを説明します。
3.3 Application notification
3.3 アプリケーション通知
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,
小川が受信機から反響を調べるとき、それは、混雑の損失などの事件に関するCMを知らせるのに、cm_アップデート(i32cm_streamid、u32 nrecd、u32 nlost、u8 lossmode、i32 rtt)を使用しなければなりません。
Balakrishnan, et. al. Standards Track [Page 9] RFC 3124 The Congestion Manager June 2001
et Balakrishnan、アル。 規格は混雑マネージャ2001年6月にRFC3124を追跡します[9ページ]。
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.
うまくいっているレセプション、損失(タイムアウトイベント、Explicit Congestion Notification[Ramakrishnan99]など)と往復の時間のサンプルのタイプ。 nrecdパラメタは、nrecdパラメタが、いくつのバイトが受け取られたかを特定する間の最後のcm_アップデート呼び出しが同じ期間、失われたのでいくつのバイトが受信機によって首尾よく受け取られたかを示します。 rtt値はこれらのバイトの送信の間に測定された往復の時間を示します。 アプリケーションでどんな有効な往復のサンプルも入手しなかったなら、rtt値を-1に設定しなければなりません。 lossmodeパラメタは損失がどう検出されたかに関するインディケータを提供します。 CM_いいえ_FEEDBACKの値は、アプリケーションがすべての傑出しているデータのためにフィードバックを全く受けていなくて、これをCMに報告しているのを示します。 例えば、タイムアウトを経験したTCPは、このCMを知らせるのにこのパラメタを使用するでしょう。 CM_LOSS_FEEDBACKの値は、アプリケーションがそれが混雑のためであると信じているいくらかの損失になりましたが、すべての傑出しているデータが失われるというわけではなかったのを示します。 例えば、写し(選択している)承認か他のデータ駆動型のテクニックを使用するのが検出されたTCPセグメントの損失はこのカテゴリに合います。 CM_EXPLICIT_CONGESTIONの値は、受信機が明白な混雑通知メッセージを反映したのを示します。 最終的に、CM_いいえ_CONGESTIONの値は、どんな混雑関連の損失も発生していないのを示します。 ビットが_CMいいえ_FEEDBACK、_CM LOSS_FEEDBACK、_CM EXPLICIT_CONGESTION、および_CMいいえ_CONGESTIONに対応しているところでしばらく-ベクトルとしてlossmodeパラメタを報告しなければなりません。 どんな_CONGESTION分野も設定しなかったCM_で混雑以外の理由、アプリケーションのための損失を経験するリンク(経路)の上では、SHOULDが損失の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.
_がデータがnsentバイトがただ与えられた流れに伝えられたことをCMに知らせるためにホスト(例えば、IP出力ルーチンにおける)から送られるとき、呼ばなければならないように(i32cm_streamid、u32 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.
cmapp_は往復の現代について、より大きい状態でCMからアプリケーションまでの交付金が満了時間だけ有効であって、等しい()を送ります、そして、cmapp_への議論が() 回収機能を送るのに応じて、実現依存する敷居は交信しました。 アプリケーションは今回が期限が切れた後にこの回収に基づくデータを送ってはいけません。 SHOULD呼び出しcm_は、その上、アプリケーションが、この回収を受けた後にデータを送らないと決めるなら、macroflowの他の流れがデータを送ることを許可するようにCMを許容する(流れ_インフォメーション、0)に通知します。 CM混雑コントローラが_が正しく通知する(流れ_インフォメーション、0)cmを呼び出すのを忘れるアプリケーションに強健であるに違いありませんか、またはcm_要求を()にした後にクラッシュするか、または見えなくなるアプリケーションは呼びます。
Balakrishnan, et. al. Standards Track [Page 10] RFC 3124 The Congestion Manager June 2001
et Balakrishnan、アル。 規格は混雑マネージャ2001年6月にRFC3124を追跡します[10ページ]。
3.4 Querying
3.4 質問
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.
アプリケーションが、1流れあたりの利用可能な帯域幅と往復の時頃に必要な量に記入するCMのcm_質問(i32cm_streamid、i64*は評価します、i32*srtt、i32*rttdev)呼び出しは使用できることを学びたいなら。 CMにmacroflowに、有効な見積りがないなら、それはレート、srtt、およびrttdevのために負の数に記入します。
3.5 Sharing granularity
3.5 粒状を共有すること。
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つは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(i32cm_streamid)はユニークなi32 macroflow識別子を返します。cm_setmacroflow(i32cm_macroflowid、i32cm_streamid)は流れのcm_streamidのmacroflowをcm_macroflowidに設定します。 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装置の後ろに受信機のグループがあるとき、例えば、送付者はそれらを皆、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
このインタフェースの目的はグループがmacroflowの流れの相対重量の方針を共有しないのを共有しながらセットアップすることです。 後者は、設定するインタフェースを提供するために方針を共有しながら、スケジューラを必要とします。 しかしながら、多くの異なったスケジューラ(それのそれぞれが方針を設定するために異なった情報を必要とするかもしれない)を支持したいと思うので私たちが完全なAPIをスケジューラに指定しない、(見てください。
Balakrishnan, et. al. Standards Track [Page 11] RFC 3124 The Congestion Manager June 2001
et Balakrishnan、アル。 規格は混雑マネージャ2001年6月にRFC3124を追跡します[11ページ]。
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について説明すると予想されます。
4. CM internals
4. CMインターナル
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の内部の成分について説明します。 それはCongestion Controllerと明確で、抽象的なインタフェースが輸出されているSchedulerを含んでいます。
4.1 Congestion controller
4.1 混雑コントローラ
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のための見積率(bpsにおける)と平坦な周遊旅行時間(マイクロセカンドの)を返します。
- 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
- アップデート(u32 nsent、u32 nrecd、u32 rtt、u32 lossmode)を欠如させてください: macroflowに関連しているCMの流れのどれかが、データが受信機に達したか、または途中で失われたのを特定するときはいつも、この機能は呼ばれます。 nrecdパラメタはちょうど受信機に到着したバイト数を示します。そしてnsentパラメタがただ受け取られたバイト数の合計である。
Balakrishnan, et. al. Standards Track [Page 12] RFC 3124 The Congestion Manager June 2001
et Balakrishnan、アル。 規格は混雑マネージャ2001年6月にRFC3124を追跡します[12ページ]。
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).
途中で失われているように特定されたバイト数。 転送の間のマイクロセカンドの時に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)と呼ばなければなりません。
4.2 Scheduler
4.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:
Schedulerは以下のインタフェースを実行しなければなりません:
- 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_バイト)を欠如させてください: 輻輳制御モジュールが、データを送ることができることを決定すると、送ることができないバイト数しかスケジュール()ルーチンを呼ばなければなりません。 順番に、スケジューラは、_が()を送るcmappをCMアプリケーションが提供しなければならない機能と呼ぶかもしれません。
- 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.
- 質問_株式(i32cm_streamid)を発行してください: この呼び出しは説明された流れのmacroflowに利用可能な総帯域幅のシェアを返します。 混雑コントローラの質問呼び出しに結合されたこの呼び出しは、アプリケーションのcm_質問()要求を満たすために情報を提供します。
- 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.
- 空間は(i32cm_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.
Schedulerは多くの追加インタフェースを実行するかもしれません。 CMスケジューラの経験が増加するのに従って、将来のドキュメントはスケジューラAPIのいくつかの部分への追加、そして/または、変更を行うかもしれません。
Balakrishnan, et. al. Standards Track [Page 13] RFC 3124 The Congestion Manager June 2001
et Balakrishnan、アル。 規格は混雑マネージャ2001年6月にRFC3124を追跡します[13ページ]。
5. Examples
5. 例
5.1 Example applications
5.1 例のアプリケーション
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つの可能な用途について説明します。 私たちは2つの非同期なアプリケーションについて説明します。---TCP送付者の実現と混雑の実現はUDPソケット、および同期アプリケーションを制御しました。---. 効率的な操作のためのこれらのアプリケーションと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を使用するすべてのアプリケーションが受信機からフィードバックを取り入れなければなりません。例えば、それは、定期的にパケットのいくつが受信機に到着したかを決定しなければなりません(一度か二度周遊旅行単位で通常調節します)。ソースがこのフィードバックを得るとき、この新情報のCMを知らせるのにcm_アップデート()を使用しなければなりません。 これは、owndをアップデートするCMをもたらして、見積りを変えて、cmappをmacroflowの流れの_アップデート()と呼ぶCMをもたらすかもしれません。
The protocols in this section are examples and suggestions for implementation, rather than requirements for any conformant implementation.
このセクションのプロトコルは、どんなconformant実現のための要件よりもむしろ実現のための例と提案です。
5.1.1 TCP
5.1.1 TCP
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実現は_が() 回収APIを送るcmappを使用するべきです。 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_戸外の()要求を実行します。
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
接続がいったん確立されると、CMは、発信データの伝達を制御するのに使用されます。 CMはTCPで混雑に追跡して、反応する必要性を排除します、CMとそのトランスミッションAPIが適切な混雑の振舞いを確実にするので。 損失回復はタイムアウトと同様に速い「再-トランスミッション」と回復に基づくTCPによってまだ実行されています。 また、さらに、TCPは、それ自身の傑出している窓(tcp_ownd)の見積りを持つように変更されます。 _cmappからデータ・セグメントを送るときはいつも、tcp_ownd値を()回収、TCPアップデートに送ってください。 また、それぞれのcm_アップデート()呼び出しの後にownd変数をアップデートします。 また、TCPは傑出しているセグメント(pkt_cnt)の数のカウントを維持します。 いつでも、TCPはtcp_ownd/pkt_cntとして平均したパケットサイズ(avg_pkt_サイズ)について計算できます。 avg_pkt_サイズはTCPによって使用されます。
Balakrishnan, et. al. Standards Track [Page 14] RFC 3124 The Congestion Manager June 2001
et Balakrishnan、アル。 規格は混雑マネージャ2001年6月にRFC3124を追跡します[14ページ]。
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.
助けるには、傑出しているデータの量を見積もってください。 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出力ルーチンはすべての非混雑チェック(ネーグルアルゴリズム、受信機の広告を出している窓のチェックなど)を実行します。 これらのチェックが終わるなら、出力ルーチンは、流れのためにデータを列に並ばせて、cm_要求()と呼びます。
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_要求()は流れのために呼ばれます。
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は出力ルーチンに用意ができています。 何か「再-トランスミッション」が待ち行列に入れられるなら、ルーチンは「再-トランスミッション」を出力します。 さもなければ、TCP接続州が許容するようにルーチンは同じくらい多くの新しいデータを出力します。 しかしながら、_が決して送らないcmappは1呼び出しあたり1つのただ一つのセグメントより発信します。 このルーチンは、ヘッダーやオプション計算のように他の出力計算をするように手配します。
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と呼びます。 _どのcmを知らないかので、streamidはパケット(_が主張(流れ_インフォメーションが含むべきであることに関してセクション4を見る)として流れ_インフォメーションをみなすように()に通知するcm)に責任があります。 _がIPペイロードサイズを報告するように()に通知するcm、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. 標準としてタイムスタンプかKarnのアルゴリズムのどちらかを使用することでRTT見積りをします。 cm_アップデート呼び出しで発生するどんなrtt見積りも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_最大-ack-1(すなわち、MAX Sequence Sent--現在のAck--1)として_飛行における(飛行でのデータ量)の値を計算します。 そして、TCPは、cm_アップデートを(streamid、_飛行、0、_CM_いいえ、CONGESTION、rttのtcp_ownd)と呼びます。
Balakrishnan, et. al. Standards Track [Page 15] RFC 3124 The Congestion Manager June 2001
et Balakrishnan、アル。 規格は混雑マネージャ2001年6月にRFC3124を追跡します[15ページ]。
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つのパケットがこれらの写しacksを発生させるように到着したと仮定します。 したがって、それは、cm_アップデートを(streamid、4*avg_pkt_サイズ、3*avg_pkt_サイズ、CM_LOSS_FEEDBACK、rtt)と呼びます。 承認が、ちょうどどのくらいのデータがもう一方の端に達したかを示さないので、平均したパケットサイズは使用されています。 ほとんどのTCP実現が完全なMSSが目的地に到着したという指示として写しACKを解釈します。 新しいACKがいったん受け取られているようになると、これらのTCP送付者実現はTCP受信機で再連動するかもしれません。TCPがこの再同期から情報を通過するように、CM APIはメカニズムを提供しません。 したがって、TCPはそれぞれの写しackからのavg_pkt_サイズデータ量の到着を推論できるだけです。 TCPは、また、無くなっているセグメントの「再-トランスミッション」を待ち行列に入れて、cm_要求()と呼びます。 dup_acks>3であるなら、TCPはパケットでもう一方の端に達して、このackを送ったと仮定します。 その結果、それは、cm_アップデートを(streamid、avg_pkt_サイズ、avg_pkt_サイズ、_CM_いいえ、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_アップデートを(streamid、2*avg_pkt_サイズ、avg_pkt_サイズ、_CM_いいえ、CONGESTION、rtt)と呼びます。 損失の期間が既に報告されたので、CM_いいえ、_CONGESTIONは使用されています。 TCPは、また、無くなっているセグメントの「再-トランスミッション」を待ち行列に入れて、cm_要求()と呼びます。
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再送信タイマーが期限が切れると、送付者は、セグメントが失われたのを特定して、受信機からフィードバックを全く受け取っていなくて、1つのセグメントが「パイプを残します」と確信しているのを意味するようにcm_アップデート(streamid、avg_pkt_サイズ、0、_CM_いいえ、FEEDBACK、0)と呼びます。 TCPは、また、無くなっているセグメントの「再-トランスミッション」を待ち行列に入れて、cm_要求()と呼びます。
5.1.2 Congestion-controlled UDP
5.1.2 混雑で制御されたUDP
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
混雑で制御されたUDPは役に立つCMアプリケーションです。(私たちはバークレーソケット[Stevens94]の文脈でそのアプリケーションについて説明します)。 彼らが標準のバークレーUDPソケットと同じ機能性を提供しますが、すぐにトランスミッションのために層を下ろすためにカーネルパケット待ち行列からデータを送ることの代わりに、バッファリングされたソケット実現は、カーネルの中でCMでAPIへの呼び出しを輸出させて、CMから回収を得ます。 CM UDPソケットが作成されるとき、それは特定の流れに縛られます。 データが交際した流れのときにその後パケット待ち行列に加えられるとき、cm_要求()は呼ばれます。
Balakrishnan, et. al. Standards Track [Page 16] RFC 3124 The Congestion Manager June 2001
et Balakrishnan、アル。 規格は混雑マネージャ2001年6月にRFC3124を追跡します[16ページ]。
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.
ソケット。 CMがトランスミッションのためのこの流れの計画をするとき、それは、UDPモジュールでudp_をccappsend()と呼びます。 この機能は、パケット待ち行列から1MTUを伝えて、どんな残っているパケットのトランスミッションも計画をします。 カーネルにおける、CM UDP APIの実現は、少しの追加データコピーも必要とするべきでなくて、すべての標準のUDPオプションをサポートするべきです。 混雑で制御されたUDPを使用するように既存のアプリケーションを変更するのはソケットにおける新しいソケットオプションの実現を必要とします。 正しく働くために、送付者は混雑に関するフィードバックを得なければなりません。 少なくとも2つの方法でこれができます: (i) UDP受信側アプリケーションは送付者アプリケーションにフィードバックを提供できます。(それは、cm_アップデート()を使用することでネットワーク状態のCMを知らせるでしょう)。 (ii) UDP受信機実現は発信しているUDPにフィードバックを供給できます。 この後者の代替手段が受信機のネットワークスタックへの変化を必要として、送付者UDPが、すべての受信機が明白な交渉なしでこのオプションをサポートすると仮定できないことに注意してください。
5.1.3 Audio server
5.1.3 オーディオサーバ
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_質問()要求を使用します。 そのmacroflowにおけるある他の流れが既に活発であるなら、有効な初期の見積りを得ます。 さもなければ、それは負の数を得ます。(それは負の数を無視します)。 見積もって(または、無効の見積りの場合では、アプリケーション特有の初期の値を使用します)、データを送り始めます次に、それが、これらを超えていないコード化を選ぶ。 また、アプリケーションはcmapp_アップデート()回収を実行します。 CMが、ネットワークの特性が変化したことを決定すると、それは、アプリケーションのcmapp_アップデート()機能と呼んで、新しいレートと往復の時間見積りにそれに合格します。 アプリケーションは、これらの新しい見積りを超えていないのを保証するためにオーディオコード化の選択を変えなければなりません。
Balakrishnan, et. al. Standards Track [Page 17] RFC 3124 The Congestion Manager June 2001
et Balakrishnan、アル。 規格は混雑マネージャ2001年6月にRFC3124を追跡します[17ページ]。
5.2 Example congestion control module
5.2例の輻輳制御モジュール
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):
輻輳制御モジュールの責任を例証するために、以下はAdditive Increase Multiplicative Decrease輻輳制御(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をアップデートします。 アップデートが、データが失われたのを示すなら、CM_いいえ_FEEDBACKとcwnd/2(最低1MTUと)に損失_モードが損失_モードがCM_LOSS_FEEDBACKかCM_EXPLICIT_CONGESTIONであるならあるなら、AIMD_CCは1MTUにcwndを設定します。 また、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がいつアップデートして、その少なくとも1MTUを示すかは伝えられるかもしれなくて、AIMD_CC呼び出しはトランスミッションの計画をするCMです。
5.3 Example Scheduler Module
5.3例のスケジューラモジュール
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).
- _シェア()について質問してください: _がschedしたRRは1/(macroflowの流れの数)を返します。
- notify(): RR_sched does nothing. Round robin scheduling is not
affected by the amount of data sent.
- ()に通知してください: _がschedしたRRは何もしません。 連続スケジューリングは送られたデータ量で影響を受けません。
6. Security Considerations
6. セキュリティ問題
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
CMはTCPの輻輳制御が提供する同じサービスの多くを提供します。 そしてそういうものとして、それが同じ警備上の問題例えば、損失に関する不正確な報道の多くに傷つきやすい。
Balakrishnan, et. al. Standards Track [Page 18] RFC 3124 The Congestion Manager June 2001
et Balakrishnan、アル。 規格は混雑マネージャ2001年6月にRFC3124を追跡します[18ページ]。
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に与えるでしょう。 混雑の重要視を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]で、覆われない)は起こります。 例えば、不十分に設計されたa、ことによるとaが妥協したか、または故意に悪意があるUDPアプリケーションは、macroflowの他のものの飢餓、そして/または、また、攻撃的な振舞いを引き起こすためにcm_アップデート()を誤用するかもしれません。
7. References
7. 参照
[Allman99] Allman, M. and Paxson, V., "TCP Congestion
Control", RFC 2581, April 1999.
[Allman99] オールマンとM.とパクソン、V.、「TCP輻輳制御」、RFC2581、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での満足している適合。 第4Sympオペレーティングシステム設計と実装、サンディエゴ(カリフォルニア)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.とキャッツ、R.、「忙しいウェブサーバーのTCP働き:」 「分析と改良」、Proc。 1998年のIEEE INFOCOM、サンフランシスコ(カリフォルニア)の行進。
[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、ケンブリッジ(MA)1999年9月。
[Bradner96] Bradner, S., "The Internet Standards Process ---
Revision 3", BCP 9, RFC 2026, October 1996.
[Bradner96] ブラドナー、S.、「インターネット標準化過程」--- 改正3インチ、BCP9、RFC2026、1996年10月。
[Bradner97] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[Bradner97] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
Balakrishnan, et. al. Standards Track [Page 19] RFC 3124 The Congestion Manager June 2001
et Balakrishnan、アル。 規格は混雑マネージャ2001年6月にRFC3124を追跡します[19ページ]。
[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.、「アンサンブルTCPの効果」ACMコンピュータ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]フロイドとS.とFall、K.」、インターネット」 (IEEE/ACM Trans)での存在終わりまでのEnd Congestion ControlのPromoting Use、Networking、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の速い回復アルゴリズムへの新しいリノ変更」、RFC2582、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発見」、RFC1191、1990年11月。
[Padmanabhan98] Padmanabhan, V., "Addressing the Challenges of Web
Data Transport," PhD thesis, Univ. of California,
Berkeley, December 1998.
V. [Padmanabhan98]Padmanabhan、「ウェブデータ伝送の挑戦を記述すること」での博士論文、カリフォルニア、バークレー、1998年12月の大学。
[Paxson00] Paxson, V. and M. Allman, "Computing TCP's
Retransmission Timer", RFC 2988, November 2000.
[Paxson00] パクソンとV.とM.オールマン、「コンピューティングTCPの再送信タイマー」、RFC2988、2000年11月。
[Postel81] Postel, J., Editor, "Transmission Control
Protocol", STD 7, RFC 793, September 1981.
[Postel81] ポステル、J.、エディタ、「通信制御プロトコル」、STD7、RFC793、1981年9月。
[Ramakrishnan99] Ramakrishnan, K. and Floyd, S., "A Proposal to Add
Explicit Congestion Notification (ECN) to IP," RFC
2481, January 1999.
1999年1月の[Ramakrishnan99]Ramakrishnan、K.とフロイド、S.、「明白な混雑通知(電子証券取引ネットワーク)をIPに追加するという提案」RFC2481。
[Stevens94] Stevens, W., TCP/IP Illustrated, Volume 1.
Addison-Wesley, Reading, MA, 1994.
w.[Stevens94]スティーブンス、TCP/IPは例証して、ボリュームは1です。 アディソン-ウエスリー、読書、MA、1994。
[Touch97] Touch, J., "TCP Control Block Interdependence", RFC
2140, April 1997.
[Touch97] 接触、J.、「TCP制御ブロック相互依存」、RFC2140、1997年4月。
Balakrishnan, et. al. Standards Track [Page 20] RFC 3124 The Congestion Manager June 2001
et Balakrishnan、アル。 規格は混雑マネージャ2001年6月にRFC3124を追跡します[20ページ]。
8. Acknowledgments
8. 承認
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設計と実装に対する彼らの仕事についてデヴィッド・アンダーセン、Deepak Bansal、およびドロシー・カーティスに感謝します。 彼の詳細なコメント、フィードバック、および忍耐についてバーン・パクソンに感謝します、そして、私たちは、CM構造の役に立つフィードバックのためにサリー・フロイド、マーク・ハンドレー、およびスティーブンMcCanneに感謝します。 アリソン・マンキンとジョーTouchはこのドキュメントの前の草稿のいくつかの役に立つコメントを提供しました。
9. Authors' Addresses
9. 作者のアドレス
Hari Balakrishnan Laboratory for Computer Science 200 Technology Square Massachusetts Institute of Technology Cambridge, MA 02139
ハーリBalakrishnanコンピュータ科学研究所200の技術の正方形のマサチューセッツ工科大学ケンブリッジ、MA 02139
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
Srinivasan Seshanコンピュータサイエンスカーネギーメロン大学5000学校フォーブズAve。 ピッツバーグ、PA 15213
EMail: srini@cmu.edu Web: http://www.cs.cmu.edu/~srini/
メール: srini@cmu.edu ウェブ: http://www.cs.cmu.edu/~srini/
Balakrishnan, et. al. Standards Track [Page 21] RFC 3124 The Congestion Manager June 2001
et Balakrishnan、アル。 規格は混雑マネージャ2001年6月にRFC3124を追跡します[21ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Balakrishnan, et. al. Standards Track [Page 22]
et Balakrishnan、アル。 標準化過程[22ページ]
一覧
スポンサーリンク
