Network Working Group S. Floyd
Request for Comments: 4336 ICIR
Category: Informational M. Handley
UCL
E. Kohler
UCLA
March 2006
Problem Statement for the
Datagram Congestion Control Protocol (DCCP)
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This document describes for the historical record the motivation behind the Datagram Congestion Control Protocol (DCCP), an unreliable transport protocol incorporating end-to-end congestion control. DCCP implements a congestion-controlled, unreliable flow of datagrams for use by applications such as streaming media or on-line games.
この文書は、履歴レコードのデータグラム輻輳制御プロトコル（DCCP）、エンドツーエンドの輻輳制御を組み込んだ信頼性の低いトランスポートプロトコルの背後にある動機を記載しています。 DCCPは、このようなストリーミングメディアやオンラインゲームなどのアプリケーションで使用するためのデータグラムの輻輳制御、信頼性の低いフローを実装しています。
Table of Contents
目次
1. Introduction ....................................................2
2. Problem Space ...................................................3
2.1. Congestion Control for Unreliable Transfer .................4
2.2. Overhead ...................................................6
2.3. Firewall Traversal .........................................6
2.4. Parameter Negotiation ......................................7
3. Solution Space for Congestion Control of Unreliable Flows .......7
3.1. Providing Congestion Control Above UDP .....................8
3.1.1. The Burden on the Application Designer ..............8
3.1.2. Difficulties with ECN ...............................8
3.1.3. The Evasion of Congestion Control ..................10
3.2. Providing Congestion Control Below UDP ....................10
3.2.1. Case 1: Congestion Feedback at the Application .....11
3.2.2. Case 2: Congestion Feedback at a Layer Below UDP ...11
3.3. Providing Congestion Control at the Transport Layer .......12
3.3.1. Modifying TCP? .....................................12
3.3.2. Unreliable Variants of SCTP? .......................13
3.3.3. Modifying RTP? .....................................14
3.3.4. Designing a New Transport Protocol .................14
4. Selling Congestion Control to Reluctant Applications ...........15
5. Additional Design Considerations ...............................15
6. Transport Requirements of Request/Response Applications ........16
7. Summary of Recommendations .....................................17
8. Security Considerations ........................................18
9. Acknowledgements ...............................................18
Informative References ............................................19
Historically, the great majority of Internet unicast traffic has used congestion-controlled TCP, with UDP making up most of the remainder. UDP has mainly been used for short, request-response transfers, like DNS and SNMP, that wish to avoid TCP's three-way handshake, retransmission, and/or stateful connections. UDP also avoids TCP's built-in end-to-end congestion control, and UDP applications tended not to implement their own congestion control. However, since UDP traffic volume was small relative to congestion-controlled TCP flows, the network didn't collapse.
歴史的に、インターネットのユニキャストトラフィックの大多数は、UDPは、残りの大部分を構成すると、輻輳制御のTCPを使用しています。 UDPは、主にTCPの3ウェイハンドシェイク、再送信、および/またはステートフル接続を避けたいDNSおよびSNMP、のような、短い、要求 - 応答の転送に使用されてきました。 UDPもTCPの組み込みのエンドツーエンドの輻輳制御を回避し、UDPアプリケーションでは、独自の輻輳制御を実装していない傾向が見られました。しかし、UDPトラフィック量が輻輳制御のTCPフローに対する小さいため、ネットワークが崩壊していませんでした。
Recent years have seen the growth of applications that use UDP in a different way. These applications, including streaming audio, Internet telephony, and multiplayer and massively multiplayer on-line games, share a preference for timeliness over reliability. TCP can introduce arbitrary delay because of its reliability and in-order delivery requirements; thus, the applications use UDP instead. This growth of long-lived non-congestion-controlled traffic, relative to congestion-controlled traffic, poses a real threat to the overall health of the Internet [RFC2914, RFC3714].
近年、さまざまな方法でUDPを使用するアプリケーションの成長を見てきました。ストリーミングオーディオ、インターネット電話、およびマルチプレイヤーと多人数参加型のオンラインゲームを含むこれらのアプリケーションは、信頼性の上に適時のための好みを共有しています。 TCPは、その信頼性とで順序どおりの配信要件任意の遅延を導入することができます。したがって、アプリケーションでは、代わりにUDPを使用しています。長寿命の非輻輳制御トラフィックのこの成長は、輻輳制御トラフィックに比べて、インターネット[RFC2914、RFC3714]の全体的な健康への本当の脅威となります。
Applications could implement their own congestion control mechanisms on a case-by-case basis, with encouragement from the IETF. Some already do this. However, experience shows that congestion control is difficult to get right, and many application writers would like to avoid reinventing this particular wheel. We believe that a new protocol is needed, one that combines unreliable datagram delivery with built-in congestion control. This protocol will act as an enabling technology: existing and new applications could easily use it to transfer timely data without destabilizing the Internet.
アプリケーションは、IETFからの励ましで、ケースバイケースで、独自の輻輳制御機構を実装することができます。いくつかはすでにこれを行います。しかし、経験は、輻輳制御が権利を取得することは困難であることを示しており、多くのアプリケーション作成者は、この特定の車輪の再発明避けたいです。私たちは、新しいプロトコルが必要であること、組み込みの輻輳制御と信頼性のないデータグラムの配信を組み合わせたものを信じています。このプロトコルは、実現技術として機能します：既存および新規のアプリケーションが簡単にインターネットを不安定にすることなく、タイムリーなデータを転送するためにそれを使用することができます。
This document provides a problem statement for such a protocol. We list the properties the protocol should have, then explain why those properties are necessary. We describe why a new protocol is the best solution for the more general problem of bringing congestion control to unreliable flows of unicast datagrams, and discuss briefly subsidiary requirements for mobility, defense against Denial of Service (DoS) attacks and spoofing, interoperation with RTP, and interactions with Network Address Translators (NATs) and firewalls.
この文書では、そのようなプロトコルのための問題文を提供します。私たちは、これらのプロパティが必要な理由を説明、その後、プロトコルが持つべきプロパティを一覧表示します。私たちは、RTPとの相互運用、サービス拒否に対する防衛（DoS）攻撃やスプーフィング、新しいプロトコルは、ユニキャストデータグラムの信頼性の低いフローに輻輳制御をもたらす、より一般的な問題のために最善の解決策である理由を説明、およびモビリティのために簡単に子会社の要件を議論しますおよびネットワークアドレス変換（NAT）とファイアウォールとの相互作用。
One of the design preferences that we bring to this question is a preference for a clean, understandable, low-overhead, and minimal protocol. As described later in this document, this results in the design decision to leave functionality such as reliability or Forward Error Correction (FEC) to be layered on top, rather than provided in the transport protocol itself.
私たちはこの質問にもたらすデザインの好みの一つは、きれいに理解、低オーバーヘッド、および最小限のプロトコルのための好みです。本書で後述するように、これは、信頼性や前方誤り訂正（FEC）の上に重層ではなく、トランスポートプロトコル自体に提供されるような機能性を残すために設計上の決定をもたらします。
This document began in 2002 as a formalization of the goals of DCCP, the Datagram Congestion Control Protocol [RFC4340]. We intended DCCP to satisfy this problem statement, and thus the original reasoning behind many of DCCP's design choices can be found here. However, we believed, and continue to believe, that the problem should be solved whether or not DCCP is the chosen solution.
この文書では、DCCPの目標の形式化、データグラム輻輳制御プロトコル[RFC4340]として2002年に始まりました。私たちは、この問題文を満たすためにDCCPを意図したため、DCCPのデザインの選択の多くの背後にある本来の理由はここにあります。しかし、私たちは信じて、問題がDCCPが選ばれたソリューションであるか否かの解決すべきことを、信じ続けます。
We perceive a number of problems related to the use of unreliable data flows in the Internet. The major issues are the following:
私たちは、インターネットにおける信頼性のないデータ・フローの使用に関連する多くの問題を認識します。主要な問題は次のとおりです。
o The potential for non-congestion-controlled datagram flows to cause congestion collapse of the network. (See Section 5 of [RFC2914] and Section 2 of [RFC3714].)
O非輻輳制御データグラムの可能性は、ネットワークの輻輳崩壊を引き起こすことが流れ込みます。 （[RFC2914]及び[RFC3714]のセクション2のセクション5を参照）。
o The difficulty of correctly implementing effective congestion control mechanisms for unreliable datagram flows.
正しく信頼性のないデータグラムフローのための効果的な輻輳制御機構を実装することの難しさ、O。
o The lack of a standard solution for reliably transmitting congestion feedback for an unreliable data flow.
確実に信頼性のないデータ・フローのための輻輳フィードバックを送信するための標準溶液の欠如O。
o The lack of a standard solution for negotiating Explicit Congestion Notification (ECN) [RFC3168] usage for unreliable flows.
信頼性の低いフローの明示的輻輳通知（ECN）[RFC3168]使用を交渉するための標準液の欠如O。
o The lack of a choice of TCP-friendly congestion control mechanisms.
TCPフレンドリーな輻輳制御機構の選択の欠如、O。
We assume that most application writers would use congestion control for long-lived unreliable flows if it were available in a standard, easy-to-use form.
我々は、それが、標準で使いやすい形入手できた場合は、ほとんどのアプリケーションの作成者は、長寿命、信頼性の低いフローのための輻輳制御を使用することを想定しています。
More minor issues include the following:
その他のマイナーな問題は、次のものがあります。
o The difficulty of deploying applications using UDP-based flows in the presence of firewalls.
ファイアウォールの存在下でUDPベースのフローを使用してアプリケーションをデプロイすることの困難O。
o The desire to have a single way to negotiate congestion control parameters for unreliable flows, independently of the signalling protocol used to set up the flow.
信頼性の低いフローの輻輳制御パラメータを交渉するために単一の方法を持っていたいという願望O、独立して、フローを設定するために使用されるシグナリングプロトコル。
o The desire for low per-packet byte overhead.
低パケットごとのバイトのオーバーヘッドのための欲求O。
The subsections below discuss these problems of providing congestion control, traversing firewalls, and negotiating parameters in more detail. A separate subsection also discusses the problem of minimizing the overhead of packet headers.
以下のサブセクションでは、輻輳制御を提供するファイアウォールを通過し、より詳細にパラメータを交渉のこれらの問題を議論します。別個のサブセクションでは、パケットヘッダのオーバーヘッドを最小化する問題を論じています。
We aim to bring easy-to-use congestion control mechanisms to applications that generate large or long-lived flows of unreliable datagrams, such as RealAudio, Internet telephony, and multiplayer games. Our motivation is to avoid congestion collapse. (The short flows generated by request-response applications, such as DNS and SNMP, don't cause congestion in practice, and any congestion control mechanism would take effect between flows, not within a single end-to-end transfer of information.) However, before designing a congestion control mechanism for these applications, we must understand why they use unreliable datagrams in the first place, lest we destroy the very properties they require.
私たちは、このようなのRealAudio、インターネット電話、およびマルチプレイヤーゲームとして信頼性のないデータグラムの大規模または長寿命のフローを生成するアプリケーションに簡単に使用できる輻輳制御メカニズムをもたらすことを目指しています。私たちの動機は、輻輳崩壊を避けるためです。 （例えば、DNSおよびSNMPなどの要求応答アプリケーションによって生成された短いフローは、実際に輻輳が発生しない、任意の輻輳制御機構は流れの間ではなく、情報の単一のエンドツーエンドの転送中に有効になります。）我々は、彼らが必要と非常に性質を破壊しないように、彼らは、最初の場所で信頼性のないデータグラムを使用する理由しかし、これらのアプリケーションのための輻輳制御機構を設計する前に、我々は理解しなければなりません。
There are several reasons why protocols currently use UDP instead of TCP, among them:
プロトコルは現在、それらの間で、TCPの代わりにUDPを使用する理由はいくつかあります：
o Startup Delay: they wish to avoid the delay of a three-way handshake before initiating data transfer.
起動遅延O：彼らは、データ転送を開始する前に、3ウェイハンドシェイクの遅延を回避したいです。
o Statelessness: they wish to avoid holding connection state, and the potential state-holding attacks that come with this.
Oの無国籍：彼らは接続状態を保持避けたい、とこの付属して潜在的な状態保持の攻撃。
o Trading of Reliability against Timing: the data being sent is timely in the sense that if it is not delivered by some deadline (typically a small number of RTTs), then the data will not be useful at the receiver.
Oタイミングに対する信頼性のトレーディング：データが送信されて、それがいくつかの期限（のRTTの典型的には少数）によって送達されていない場合、データが受信機に有用でないという意味でタイムリーです。
Of these issues, applications that generate large or long-lived flows of datagrams, such as media transfer and games, mostly care about controlling the trade-off between timing and reliability. Such applications use UDP because when they send a datagram, they wish to send the most appropriate data in that datagram. If the datagram is lost, they may or may not resend the same data, depending on whether the data will still be useful at the receiver. Data may no longer be useful for many reasons:
これらの問題の中で、そのような媒体の転送やゲームなどのデータグラムの大規模または長寿命のフローを生成するアプリケーションは、ほとんどタイミングと信頼性とのトレードオフを制御する気に。彼らはデータグラムを送信するとき、彼らはそのデータグラムの中で最も適切なデータを送信したいので、そのようなアプリケーションでは、UDPを使用しています。データグラムが失われた場合、彼らは、データがまだ受信機で有用であろうかどうかに応じて、同じデータを再送信しない場合があります。データは、もはや多くの理由のために有用でないことがあります。
o In a telephony or streaming video session, data in a packet comprises a timeslice of a continuous stream. Once a timeslice has been played out, the next timeslice is required immediately. If the data comprising that timeslice arrives at some later time, then it is no longer useful. Such applications can cope with masking the effects of missing packets to some extent, so when the sender transmits its next packet, it is important for it to only send data that has a good chance of arriving in time for its playout.
Oテレフォニーやストリーミングビデオセッションでは、パケット内のデータは連続ストリームのタイムスライスを備えます。タイムスライスが出て再生された後は、次のタイムスライスがすぐに必要とされます。そのタイムスライスを含むデータは、いくつかの後に到着した場合、それはもはや有益ではありません。このようなアプリケーションは、ある程度のパケットの欠落の影響をマスクに対応できるので、送信側はその次のパケットを送信する場合、それだけでその再生のための時間に到着のチャンスを持っているデータを送信することは重要です。
o In an interactive game or virtual-reality session, position information is transient. If a datagram containing position information is lost, resending the old position does not usually make sense -- rather, every position information datagram should contain the latest position information.
Oインタラクティブなゲームやバーチャル・リアリティのセッションでは、位置情報が一時的です。位置情報を含むデータグラムが失われた場合、古い位置を再送信することは、通常は意味がありません - むしろ、すべての位置情報データグラムは、最新の位置情報が含まれている必要があります。
In a congestion-controlled flow, the allowed packet sending rate depends on measured network congestion. Thus, some control is given up to the congestion control mechanism, which determines precisely when packets can be sent. However, applications could still decide, at transmission time, which information to put in a packet. TCP doesn't allow control over this; these applications demand it.
輻輳制御フローでは、速度の送信許可パケットは、測定されたネットワーク輻輳に依存します。したがって、いくつかの制御は、パケットを送信することができる場合に正確に決定する輻輳制御機構まで与えられます。ただし、アプリケーションは、まだパケットに入れている情報は、送信時に、決めることができました。 TCPは、このオーバー制御を許可していません。これらのアプリケーションは、それを求めています。
Often, these applications (especially games and telephony applications) work on very short playout timescales. Whilst they are usually able to adjust their transmission rate based on congestion feedback, they do have constraints on how this adaptation can be performed so that it has minimal impact on the quality of the session. Thus, they tend to need some control over the short-term dynamics of the congestion control algorithm, whilst being fair to other traffic on medium timescales. This control includes, but is not limited to, some influence on which congestion control algorithm should be used -- for example, TCP-Friendly Rate Control (TFRC) [RFC3448] rather than strict TCP-like congestion control. (TFRC has been standardized in the IETF as a congestion control mechanism that adjusts its sending rate more smoothly than TCP does, while maintaining long-term fair bandwidth sharing with TCP [RFC3448].)
多くの場合、これらのアプリケーション（特にゲームやテレフォニーアプリケーション）は、非常に短いプレイアウトタイムスケール上で動作します。彼らは通常、混雑のフィードバックに基づいて、それらの送信レートを調整することができますしながら、彼らはそれがセッションの品質への影響を最小限に抑えますように、この適応を実行することができる方法についての制約を持っています。このように、彼らはメディアタイムスケール上の他のトラフィックに公平であることながら、輻輳制御アルゴリズムの短期的なダイナミクスをある程度制御を必要とする傾向にあります。例えば、TCPフレンドリーレート制御（TFRC）[RFC3448]はなく、厳密なTCPのような輻輳制御より - この制御は、輻輳制御アルゴリズムが使用されるべきで、いくつかの影響を含むが、これらに限定されません。 （[RFC3448] TCPとの長期的公平な帯域幅共有を維持しながら、TFRCは、よりスムーズTCPはよりも、その送信レートを調整する輻輳制御機構としてIETFで標準化されています。）
The applications we are concerned with often send compressed data, or send frequent small packets. For example, when Internet telephony or streaming media are used over low-bandwidth modem links, highly compressing the payload data is essential. For Internet telephony applications and for games, the requirement is for low delay, and hence small packets are sent frequently.
我々が懸念しているアプリケーションは、多くの場合、圧縮されたデータを送ったり、頻繁に小さなパケットを送信します。例えば、インターネット電話やストリーミングメディアは、低帯域幅のモデムリンク上で使用されている場合、非常にペイロードデータを圧縮することが不可欠です。インターネット電話アプリケーションでは、ゲームのために、要件は、低遅延のためであるため、小さなパケットを頻繁に送信されます。
For example, a telephony application sending a 5.6 Kbps data stream but wanting moderately low delay may send a packet every 20 ms, sending only 14 data bytes in each packet. In addition, 20 bytes is taken up by the IP header, with additional bytes for transport and/or application headers. Clearly, it is desirable for such an application to have a low-overhead transport protocol header.
例えば、電話アプリケーション5.6 Kbpsのデータストリームを送信するが、適度に低い遅延を望むは、各パケットには14データバイトを送信し、パケットを20ミリ秒毎に送信してもよいです。また、20のバイトがトランスポートおよび/またはアプリケーションヘッダーの追加のバイトで、IPヘッダによって取り込まれます。そのようなアプリケーションは、低オーバーヘッドトランスポートプロトコルヘッダを持っているため、明らかに、それが望ましいです。
In some cases, the correct solution would be to use link-based packet header compression to compress the packet headers, although we cannot guarantee the availability of such compression schemes on any particular link.
いくつかのケースでは、正しい解決策は、我々は、任意の特定のリンク上でこのような圧縮方式の可用性を保証することはできませんが、パケットのヘッダを圧縮するために、リンクベースのパケットヘッダの圧縮を使用することであろう。
The delay of data until after the completion of a handshake also represents potentially unnecessary overhead. A new protocol might therefore allow senders to include some data on their initial datagrams.
ハンドシェイクが完了した後まで、データの遅延はまた、潜在的に不要なオーバーヘッドを表します。新しいプロトコルは、したがって、送信者が初期のデータグラム上のいくつかのデータを含めることができる場合があります。
Applications requiring a flow of unreliable datagrams currently tend to use signalling protocols such as the Real Time Streaming Protocol (RTSP) [RFC2326], SIP [RFC3261], and H.323 in conjunction with UDP for the data flow. The initial setup request uses a signalling protocol to locate the correct remote end-system for the data flow, sometimes after being redirected or relayed to other machines.
信頼性のないデータグラムの流れを必要とするアプリケーションは、現在のデータ・フローのためにUDPと組み合わせて、リアルタイムストリーミングプロトコル（RTSP）[RFC2326]、SIP [RFC3261]、およびH.323などのシグナリングプロトコルを使用する傾向があります。初期セットアップ要求は、しばしば他のマシンに転送又は中継された後、データ・フローのための正しいリモートエンドシステムの位置を確認するためにシグナリングプロトコルを使用します。
As UDP flows contain no explicit setup and teardown, it is hard for firewalls to handle them correctly. Typically, the firewall needs to parse RTSP, SIP, and H.323 to obtain the information necessary to open a hole in the firewall. Although, for bi-directional flows, the firewall can open a bi-directional hole if it receives a UDP packet from inside the firewall, in this case the firewall can't easily know when to close the hole again.
UDPフローは、明示的なセットアップとティアダウンを含まないため、ファイアウォールが正しくそれらを処理することは困難です。一般的に、ファイアウォールは、ファイアウォールに穴を開くために必要な情報を取得するためにRTSP、SIP、及びH.323を解析する必要があります。それはこの場合には、ファイアウォールの内側からのUDPパケットを受信した場合、双方向のフローのために、ファイアウォールは双方向の穴を開くことができます、が、再び穴を閉鎖する際に、ファイアウォールを簡単に知ることができません。
While we do not consider these to be major problems, they are nonetheless issues that application designers face. Currently, streaming media players attempt UDP first, and then switch to TCP if UDP is not successful. Streaming media over TCP is undesirable and can result in the receiver needing to temporarily halt playout while it "rebuffers" data. Telephony applications don't even have this option.
我々はこれらが主要な問題であることを考慮していませんが、彼らは、アプリケーション設計者が直面しているにもかかわらず問題です。現在、ストリーミングメディアプレーヤーは最初のUDPを試み、UDPが成功しなかったならば、TCPに切り替えます。 TCP上でメディアをストリーミングすることは望ましくなく、一時的に「rebuffers」データしながら、再生を停止する必要が受信機につながることができます。テレフォニーアプリケーションでも、このオプションはありません。
Different applications have different requirements for congestion control, which may map into different congestion feedback. Examples include ECN capability and desired congestion control dynamics (the choice of congestion control algorithm and, therefore, the form of feedback information required). Such parameters need to be reliably negotiated before congestion control can function correctly.
異なるアプリケーションは異なる輻輳フィードバックにマッピングすることができる輻輳制御のためのさまざまな要件を、持っています。例としては、ECN能力及び所望の輻輳制御ダイナミクス（輻輳制御アルゴリズムの選択と、したがって、必要なフィードバック情報の形式）を含みます。このようなパラメータは、輻輳制御が正しく機能することができます前に、確実に交渉する必要があります。
While this negotiation could be performed using signalling protocols such as SIP, RTSP, and H.323, it would be desirable to have a single standard way of negotiating these transport parameters. This is of particular importance with ECN, where sending ECN-marked packets to a non-ECN-capable receiver can cause significant congestion problems to other flows. We discuss the ECN issue in more detail below.
このネゴシエーションは、SIP、RTSP、およびH.323などのシグナリングプロトコルを使用して行うことができるが、これらの輸送パラメータをネゴシエートする単一の標準的な方法を有することが望ましいです。これは、他のフローに重大な輻輳問題を引き起こす可能性があります非ECN対応の受信機にECN-マークされたパケットを送信するECN、と特に重要です。私たちは、以下でより詳細にECNの問題を議論します。
We thus want to provide congestion control for unreliable flows, providing both ECN and the choice of different forms of congestion control, and providing moderate overhead in terms of packet size, state, and CPU processing. There are a number of options for providing end-to-end congestion control for the unicast traffic that currently uses UDP, in terms of the layer that provides the congestion control mechanism:
私たちは、このようにECNと輻輳制御の異なる形式の選択の両方を提供し、パケットサイズ、状態、およびCPU処理の面で適度なオーバーヘッドを提供する、信頼性の低いフローの輻輳制御を提供したいです。輻輳制御機構を提供する層の面で、現在はUDPを使用してユニキャストトラフィックのエンドツーエンドの輻輳制御を提供するための多くのオプションがあります：
o Congestion control above UDP.
UDP上のO輻輳制御。
o Congestion control below UDP.
UDP以下Oの輻輳制御。
o Congestion control at the transport layer in an alternative to UDP.
UDPの代替では、トランスポート層でのOの輻輳制御。
We explore these alternatives in the sections below. The concerns from the discussions below have convinced us that the best way to provide congestion control for unreliable flows is to provide congestion control at the transport layer, as an alternative to the use of UDP and TCP.
私たちは、以下のセクションでは、これらの選択肢を探ります。以下の議論から懸念が信頼できないフローに対する輻輳制御を提供するための最良の方法は、UDPとTCPの使用に代わるものとして、トランスポート層で輻輳制御を提供することであることを私たちに確信しています。
One possibility would be to provide congestion control at the application layer, or at some other layer above UDP. This would allow the congestion control mechanism to be closely integrated with the application itself.
一つの可能性は、アプリケーション層で、またはUDP上記他のいくつかの層で輻輳制御を提供するであろう。これは、輻輳制御機構が密接にアプリケーション自体に統合することが可能となります。
A key disadvantage of providing congestion control above UDP is that it places an unnecessary burden on the application-level designer, who might be just as happy to use the congestion control provided by a lower layer. If the application can rely on a lower layer that gives a choice between TCP-like or TFRC-like congestion control, and that offers ECN, then this might be highly satisfactory to many application designers.
UDP上の輻輳制御を提供する主要な欠点は、下位層により提供される輻輳制御を使用して同じように幸せになる可能性があるアプリケーションレベルのデザイナー、上の不要な負担を課すことです。アプリケーションは、TCP状またはTFRCのような輻輳制御の間の選択を与え、それがECNを提供しています下の層に頼ることができる場合、これは、多くのアプリケーション設計者に非常に高いといえるかもしれません。
The long history of debugging TCP implementations [RFC2525, PF01] makes the difficulties in implementing end-to-end congestion control abundantly clear. It is clearly more robust for congestion control to be provided for the application by a lower layer. In rare cases, there might be compelling reasons for the congestion control mechanism to be implemented in the application itself, but we do not expect this to be the general case. For example, applications that use RTP over UDP might be just as happy if RTP itself implemented end-to-end congestion control. (See Section 3.3.3 for more discussion of RTP.)
[RFC2525、PF01] TCPの実装をデバッグするの長い歴史は、エンドツーエンドの輻輳制御を実施する上で困難が十分に明らかになります。輻輳制御は、下位層によってアプリケーションのために提供されることが、明らかに、より堅牢です。まれに、そこにアプリケーション自体に実装される輻輳制御機構のための説得力の理由かもしれないが、我々は、これは一般的なケースであることを期待しないでください。 RTP自体は、エンドツーエンドの輻輳制御を実装している場合たとえば、UDP上のRTPを使用するアプリケーションは、同じように幸せになるかもしれません。 （RTPのより多くの議論については、セクション3.3.3を参照してください。）
In addition to congestion control issues, we also note the problems with firewall traversal and parameter negotiation discussed in Sections 2.3 and 2.4. Implementing on top of UDP requires that the application designer also address these issues.
輻輳制御の問題に加えて、我々はまた、セクション2.3と2.4で説明したファイアウォールトラバーサルおよびパラメータネゴシエーションの問題を注意してください。 UDPの上に実装することで、アプリケーションの設計者はまた、これらの問題に対処する必要があります。
There is a second problem with providing congestion control above UDP: it would require either giving up the use of ECN or giving the application direct control over setting and reading the ECN field in the IP header. Giving up the use of ECN would be problematic, since ECN can be particularly useful for unreliable flows, where a dropped packet will not be retransmitted by the data sender.
UDP上での輻輳制御を提供するとの第二の問題があります：それはECNの使用をあきらめるか、アプリケーションにIPヘッダにECNフィールドを設定し、読み込みを直接制御を与えるのいずれかが必要になります。 ECNがドロップされたパケットがデータ送信者が再送されることはありません信頼性の低いフローのために特に有用である可能性があるので、ECNの使用を放棄することは、問題となります。
With the development of the ECN nonce, ECN can be useful even in the absence of network support. The data sender can use the ECN nonce, along with feedback from the data receiver, to verify that the data receiver is correctly reporting all lost packets. This use of ECN can be particularly useful for an application using unreliable delivery, where the receiver might otherwise have little incentive to report lost packets.
ECNのナンスの発展に伴い、ECNでもネットワークサポートが存在しない場合に役立ちます。データ送信側はデータ受信が正しく、すべての失われたパケットを報告していることを確認するために、データ受信機からのフィードバックとともに、ECN nonceを使用することができます。 ECNの使用は、受信機がそうでない場合は、失われたパケットを報告するインセンティブを持っているかもしれない信頼性のない配信を使用するアプリケーションのために特に有用であることができます。
In order to allow the use of ECN by a layer above UDP, the UDP socket would have to allow the application to control the ECN field in the IP header. In particular, the UDP socket would have to allow the application to specify whether or not the ECN-Capable Transport (ECT) codepoints should be set in the ECN field of the IP header.
UDP上の層によってECNの使用を可能にするために、UDPソケットは、IPヘッダ内のECNフィールドを制御するためのアプリケーションを可能にしなければなりません。具体的には、UDPソケットは、アプリケーションがECN-可能なトランスポート（ECT）コードポイントは、IPヘッダのECNフィールドに設定されるべきかどうかを指定することを可能にしなければなりません。
The ECN contract is that senders who set the ECT codepoint must respond to Congestion Experienced (CE) codepoints by reducing their sending rates. Therefore, the ECT codepoint can only safely be set in the packet header of a UDP packet if the following is guaranteed:
ECN契約はECTコードポイントを設定し、送信者が自分の送信レートを低減することにより、輻輳経験者（CE）コードポイントに応答しなければならないということです。以下が保証されている場合ので、ECTコードポイントのみを安全にUDPパケットのパケットヘッダに設定することができます。
o if the CE codepoint is set by a router, the receiving IP layer will pass the CE status to the UDP layer, which will pass it to the receiving application at the data receiver; and
CEコードポイントがルータによって設定されている場合、O、受信IPレイヤは、データ受信機で受信側アプリケーションに渡すであろうUDP層にCE状態を通過します。そして
o upon receiving a packet that had the CE codepoint set, the receiving application will take the appropriate congestion control action, such as informing the data sender.
O CEコードポイントのセットを持っていたパケットを受信すると、受信側のアプリケーションは、データの送信者に知らせるよう、適切な輻輳制御措置を取らせていただきます。
However, the UDP implementation at the data sender has no way of knowing if the UDP implementation at the data receiver has been upgraded to pass a CE status up to the receiving application, let alone whether or not the application will use the conformant end-to-end congestion control that goes along with use of ECN.
ただし、データ送信側のUDPの実装では、データ受信機でのUDP実装は、受信側アプリケーションまでのCEステータスを渡すアプリケーションが準拠エンド・ツーを使用するかどうかはおろかにアップグレードされているかどうかを知る方法がありませんECNの使用と一緒に行く末端輻輳制御。
In the absence of the widespread deployment of mechanisms in routers to detect flows that are not using conformant congestion control, allowing applications arbitrary control of the ECT codepoints for UDP packets would seem like an unnecessary opportunity for applications to use ECN while evading the use of end-to-end congestion control. Thus, there is an inherent "chicken-and-egg" problem of whether first to deploy policing mechanisms in routers, or first to enable the use of ECN by UDP flows. Without the policing mechanisms in routers, we would not advise adding ECN-capability to UDP sockets at this time.
最後の使用を回避しながら、準拠輻輳制御を使用していないフローを検出するために、ルータにおけるメカニズムの広範な展開がない場合には、UDPパケットのためのECTコードポイントの可能なアプリケーションの任意のコントロールは、ECNを使用するアプリケーションのための不要な機会のように思われます-to-エンド輻輳制御。したがって、UDPフローによってECNの使用を可能にするためにルータにポリシングメカニズムを展開する最初の、又は最初かどうかの固有の「鶏と卵」の問題があります。ルータでのポリシングメカニズムがなければ、我々はこの時点でUDPソケットにECN-機能を追加することはお勧めしませう。
In the absence of more fine-grained mechanisms for dealing with a period of sustained congestion, one possibility would be for routers to discontinue using ECN with UDP packets during the congested period, and to use ECN only with TCP or DCCP packets. This would be a reasonable response, for example, if TCP or DCCP flows were found to be more likely to be using conformant end-to-end congestion control than were UDP flows. If routers were to adopt such a policy, then DCCP flows could be more likely to receive the benefits of ECN in times of congestion than would UDP flows.
持続的な混雑の期間に対処するため、よりきめ細かなメカニズムが存在しない場合には、一つの可能性は混雑期間中にUDPパケットをECNの使用を中止し、そして唯一のTCPまたはDCCPパケットにECNを使用するルータのためになります。 TCPまたはDCCPフローはUDPフローがいたよりも準拠のエンドツーエンドの輻輳制御を使用した可能性が高いことが判明した場合、これは、例えば、合理的な応答になります。ルータは、このような政策を採用した場合、その後、DCCPフローは、UDPフローが希望よりも混雑の時代にECNの給付を受ける可能性が高いかもしれません。
A third problem of providing congestion control above UDP is that relying on congestion control at the application level makes it somewhat easier for some users to evade end-to-end congestion control. We do not claim that a transport protocol such as DCCP would always be implemented in the kernel, and do not attempt to evaluate the relative difficulty of modifying code inside the kernel vs. outside the kernel in any case. However, we believe that putting the congestion control at the transport level rather than at the application level makes it just slightly less likely that users will go to the trouble of modifying the code in order to avoid using end-to-end congestion control.
UDP上の輻輳制御を提供する第3の問題は、アプリケーションレベルで輻輳制御に依存することは幾分容易一部のユーザーは、エンドツーエンドの輻輳制御を回避することを可能にすることです。私たちは、このようなDCCPなどのトランスポートプロトコルは、常にカーネルに実装されることを主張しませんし、どのような場合でも、カーネルの外のカーネル対内部のコードを修正するの相対的な難易度を評価しようとしないでください。しかし、我々はトランスポートレベルではなく、アプリケーションレベルでの輻輳制御を置くことは、それがわずかに少ないユーザーは、エンドツーエンドの輻輳制御を使用しないようにするために、コードを変更する手間に行くことになりますと信じています。
Instead of providing congestion control above UDP, a second possibility would be to provide congestion control for unreliable applications at a layer below UDP, with applications using UDP as their transport protocol. Given that UDP does not itself provide sequence numbers or congestion feedback, there are two possible forms for this congestion feedback:
代わりに、UDP上の輻輳制御を提供する、第2の可能性は、それらのトランスポートプロトコルとしてUDPを使用するアプリケーションで、UDP下の層で信頼できないアプリケーションのための輻輳制御を提供するであろう。 UDP自体はシーケンス番号や混雑フィードバックを提供しないことを考えると、この輻輳フィードバックのための2つの形式があります。
1) Feedback at the application: The application above UDP could provide sequence numbers and feedback to the sender, which would then communicate loss information to the congestion control mechanism. This is the approach currently standardized by the Congestion Manager (CM) [RFC3124].
1）アプリケーションにおけるフィードバック：UDP上のアプリケーションは、次いで、輻輳制御機構に損失情報を通信する送信者にシーケンス番号とフィードバックを提供することができます。これは、現在輻輳マネージャー（CM）[RFC3124]によって標準化されたアプローチです。
2) Feedback at the layer below UDP: The application could use UDP, and a protocol could be implemented using a shim header between IP and UDP to provide sequence number information for data packets and return feedback to the data sender. The original proposal for the Congestion Manager [BRS99] suggested providing this layer for applications that did not have their own feedback about dropped packets.
UDP下層で2）フィードバック：アプリケーションがUDPを使用することができ、プロトコルは、データパケットのシーケンス番号の情報を提供し、データの送信者にフィードバックを返すためにIPとUDPとの間のシムヘッダを使用して実施することができます。輻輳マネージャ[BRS99]の元の提案は、廃棄されたパケットについて、自分の意見を持っていなかったアプリケーションのために、この層を設けることを提案しました。
We discuss these two cases separately below.
私たちは、別途下記のこれらの2つの場合を議論します。
In this case, the application provides sequence numbers and congestion feedback above UDP, but communicates that feedback to a congestion manager below UDP, which regulates when packets can be sent. This approach suffers from most of the problems described in Section 3.1, namely, forcing the application designer to reinvent the wheel each time for packet formats and parameter negotiation, and problems with ECN usage, firewalls, and evasion.
この場合、アプリケーションは、UDP上記のシーケンス番号と輻輳フィードバックを提供しますが、パケットを送信することができる場合に調節UDP、以下輻輳マネージャにそのフィードバックを伝えます。このアプローチは、車輪にパケットフォーマット及びパラメータネゴシエーション、およびECNの使用、ファイアウォール、および回避の問題のために各時間を改革するために、アプリケーション設計者を強制的に、すなわち、セクション3.1に記載問題の最も苦しんでいます。
It would avoid the application writer needing to implement the control part of the congestion control mechanism, but it is unclear how easily multiple congestion control algorithms (such as receiver-based TFRC) can be supported, given that the form of congestion feedback usually needs to be closely coupled to the congestion control algorithm being used. Thus, this design limits the choice of congestion control mechanisms available to applications while simultaneously burdening the applications with implementations of congestion feedback.
これは、輻輳制御機構の制御部を実装するために必要とするアプリケーションライタを回避するであろうが、（例えば、受信機ベースTFRCなど）は、複数の輻輳制御アルゴリズムは、輻輳フィードバックの形式が通常必要であることを考慮すると、サポートされ得るか、容易には不明です密接に使用されている輻輳制御アルゴリズムに結合すること。同時に輻輳フィードバックの実装とアプリケーションに負担をかけつつ、この設計は、アプリケーションに利用可能な輻輳制御機構の選択を制限します。
Providing feedback at a layer below UDP would require an additional packet header below UDP to carry sequence numbers in addition to the 8-byte header for UDP itself. Unless this header were an IP option (which is likely to cause problems for many IPv4 routers), its presence would need to be indicated using a different IP protocol value from UDP. Thus, the packets would no longer look like UDP on the wire, and the modified protocol would face deployment challenges similar to those of an entirely new protocol.
UDPの下の層にフィードバックを提供するUDP自体の8バイトのヘッダに加えて、シーケンス番号を運ぶためにUDP以下の追加パケットのヘッダを必要とするであろう。このヘッダは、（多くのIPv4のルータの問題を引き起こす可能性がある）IPオプションをしていない限り、その存在は、UDPは異なるIPプロトコル値を使用して示される必要があります。このように、パケットは、もはやワイヤ上でUDPのように見えないだろう、と変更されたプロトコルは、完全に新しいプロトコルと同様の展開の課題に直面するだろう。
To use congestion feedback at a layer below UDP most effectively, the semantics of the UDP socket Application Programming Interface (API) would also need changing, both to support a late decision on what to send and to provide access to sequence numbers (so that the application wouldn't need to duplicate them for its own purposes). Thus, the socket API would no longer look like UDP to end hosts. This would effectively be a new transport protocol.
UDPの下の層で混雑フィードバックを使用するには最も効果的に、UDPソケットアプリケーションプログラミングインターフェイス（API）のセマンティクスにもなるように（送信するかについての後半の決定をサポートするために、シーケンス番号へのアクセスを提供するために、両方の、変更する必要があるだろうアプリケーション）は、独自の目的のためにそれらを複製する必要はありません。このように、ソケットAPIは、もはやホストを終了するにはUDPのように見えないだろう。これは、効果的に新しいトランスポートプロトコルになります。
Given these complications, it seems cleaner to actually design a new transport protocol, which also allows us to address the issues of firewall traversal, flow setup, and parameter negotiation. We note that any new transport protocol could also use a Congestion Manager approach to share congestion state between flows using the same congestion control algorithm, if this were deemed to be desirable.
これらの合併症を考えると、実際にも、私たちは、ファイアウォールトラバーサル、フロー設定、およびパラメータネゴシエーションの問題に対処することを可能にする新しいトランスポートプロトコルを設計するクリーナーと思われます。私たちは、これが望ましいとみなされた場合は、新しいトランスポートプロトコルも、同じ輻輳制御アルゴリズムを使用して、フロー間の輻輳状態を共有するために輻輳マネージャのアプローチを使用することができることに注意してください。
The concerns from the discussions above have convinced us that the best way to provide congestion control to applications that currently use UDP is to provide congestion control at the transport layer, in a transport protocol used as an alternative to UDP. One advantage of providing end-to-end congestion control in an unreliable transport protocol is that it could be used easily by a wide range of the applications that currently use UDP, with minimal changes to the application itself. The application itself would not have to provide the congestion control mechanism, or even the feedback from the data receiver to the data sender about lost or marked packets.
上記の議論からの懸念は現在、UDPを使用するアプリケーションに輻輳制御を提供するための最良の方法は、UDPの代替として使用されるトランスポートプロトコルでは、トランスポート層で輻輳制御を提供することであることを私たちに確信しています。信頼できないトランスポートプロトコルにおけるエンドツーエンドの輻輳制御を提供する一つの利点は、それが現在アプリケーション自体に最小限の変更で、UDPを使用するアプリケーションの広い範囲によって容易に使用することができることです。アプリケーション自体が失われたり、マークされたパケットに関するデータ送信側にデータ受信機から輻輳制御機構、あるいはフィードバックを提供する必要はありません。
The question then arises of whether to adapt TCP for use by unreliable applications, to use an unreliable variant of the Stream Control Transmission Protocol (SCTP) or a version of RTP with built-in congestion control, or to design a new transport protocol.
問題はその後、内蔵の輻輳制御でストリーム制御伝送プロトコル（SCTP）の信頼性の低い変異体またはRTPのバージョンを使用するか、新しいトランスポートプロトコルを設計するために、信頼できないアプリケーションで使用するためにTCPを適用するかどうかの発生します。
As we argue below, the desire for minimal overhead results in the design decision to use a transport protocol containing only the minimal necessary functionality, and to leave other functionality such as reliability, semi-reliability, or Forward Error Correction (FEC) to be layered on top.
我々は以下の議論のように、設計上の決定で最小限のオーバーヘッド結果に対する要望は、最小限必要な機能を含むトランスポート・プロトコルを使用するように、層状であることが、このような信頼性、半信頼性、または前方誤り訂正（FEC）のような他の機能を残しますトップに。
One alternative might be to create an unreliable variant of TCP, with reliability layered on top for applications desiring reliable delivery. However, our requirement is not simply for TCP minus in-order reliable delivery, but also for the application to be able to choose congestion control algorithms. TCP's feedback mechanism works well for TCP-like congestion control, but is inappropriate (or at the very least, inefficient) for TFRC. In addition, TCP sequence numbers are in bytes, not datagrams. This would complicate both congestion feedback and any attempt to allow the application to decide, at transmission time, what information should go into a packet. Finally, there is the issue of whether a modified TCP would require a new IP protocol number as well; a significantly modified TCP using the same IP protocol number could have unwanted interactions with some of the middleboxes already deployed in the network.
一つの選択肢は、信頼性が信頼性の高い配信を希望するアプリケーションのために上に重ねて、TCPの信頼性のないバリアントを作成するかもしれません。しかし、私たちの要求は単にTCPマイナスで-ため、信頼性の高い配信のためではないですが、また、アプリケーションが輻輳制御アルゴリズムを選択することができるようにするため。 TCPのフィードバック機構は、TCPのような輻輳制御に適していますが、TFRCに不適切な（または非常に少なくとも、非効率的）です。また、TCPのシーケンス番号はバイトではなく、データグラムです。これは、送信時に両方の混雑フィードバックやアプリケーションが決定できるようにする試みを、複雑になり、どのような情報は、パケットに行く必要があります。最後に、変更されたTCPは、同様に新しいIPプロトコル番号を必要とするかどうかの問題があります。同じIPプロトコル番号を使用して大幅に変更されたTCPは、すでにネットワークに配置ミドルボックスの一部との望ましくない相互作用を持つことができます。
It seems best simply to leave TCP as it is, and to create a new congestion control protocol for unreliable transfer. This is especially true since any change to TCP, no matter how small, takes an inordinate amount of time to standardize and deploy, given TCP's importance in the current Internet and the historical difficulty of getting TCP implementations right.
あるとしてTCPを残すために、信頼性の低い転送のための新たな輻輳制御プロトコルを作成するには、単に最高のようです。これは、どんなに小さな、TCPに変更するので特にそうではありません、TCPの現在のインターネットでの重要性とTCP実装は、右取得の歴史的な難しさを考えると、標準化および展開する途方もない時間がかかります。
SCTP, the Stream Control Transmission Protocol [RFC2960], was in part designed to accommodate multiple streams within a single end-to-end connection, modifying TCP's semantics of reliable, in-order delivery to allow out-of-order delivery. However, explicit support for multiple streams over a single flow at the transport layer is not necessary for an unreliable transport protocol such as DCCP, which of necessity allows out-of-order delivery. Because an unreliable transport does not need streams support, applications should not have to pay the penalties in terms of increased header size that accompany the use of streams in SCTP.
SCTP、ストリーム制御伝送プロトコル[RFC2960]は、部分的にはアウトオブオーダー配信を可能にする信頼性、順序配信のTCPのセマンティクスを変更する、単一のエンドツーエンド接続内で複数のストリームを収容するように設計されました。しかし、トランスポート層での単一のフロー上の複数のストリームの明示的なサポートは、アウトオブオーダー配信を可能にする必要性のようなDCCPなどの信頼性の低いトランスポートプロトコルのために必要ではありません。信頼性のないトランスポートがストリームのサポートを必要としないため、アプリケーションはSCTPでのストリームの使用に伴う増加したヘッダサイズの面で罰金を支払う必要はありません。
The basic underlying structure of the SCTP packet, of a common SCTP header followed by chunks for data, SACK information, and so on, is motivated by SCTP's goal of accommodating multiple streams. However, this use of chunks comes at the cost of an increased header size for packets, as each chunk must be aligned on 32-bit boundaries, and therefore requires a fixed-size 4-byte chunk header. For example, for a connection using ECN, SCTP includes separate control chunks for the Explicit Congestion Notification Echo (ECNE) and Congestion Window Reduced (CWR) functions, with the ECNE and CWR chunks each requiring 8 bytes. As another example, the common header includes a 4-byte verification tag to validate the sender.
ように基本的な基礎となるデータのためのチャンクに続く共通SCTPヘッダのSCTPパケットの構造、SACK情報とは、複数のストリームを収容SCTPの目標によって動機付けされます。しかしながら、チャンクのこの使用は各チャンクが32ビット境界で整列されなければならないように、パケットの増大ヘッダサイズを犠牲になり、したがって、固定サイズの4バイトのチャンクヘッダを必要とします。例えば、ECNを用いて接続するために、SCTPはECNEと、（CWR）関数減少明示的輻輳通知エコー（ECNE）および輻輳ウィンドウの別個の制御チャンクを含み、CWRは、それぞれ必要な8バイトチャンク。別の例として、共通ヘッダは、送信者を検証する4バイトの検証タグを含みます。
As a second concern, SCTP as currently specified uses TCP-like congestion control, and does not provide support for alternative congestion control algorithms such as TFRC that would be more attractive to some of the applications currently using UDP flows. Thus, the current version of SCTP would not meet the requirements for a choice between forms of end-to-end congestion control.
第二の懸念として、として現在指定SCTPは、TCPのような輻輳制御を使用し、現在はUDPフローを使用したアプリケーションのいくつかに、より魅力的になるようTFRCなどの代替輻輳制御アルゴリズムのためのサポートを提供していません。このように、SCTPの現在のバージョンは、エンドツーエンドの輻輳制御のフォーム間の選択のための要件を満たしていないだろう。
Finally, the SCTP Partial Reliability extension [RFC3758] allows a sender to selectively abandon outstanding messages, which ceases retransmissions and allows the receiver to deliver any queued messages on the affected streams. This service model, although well-suited for some applications, differs from, and provides the application somewhat less flexibility than, UDP's fully unreliable service.
最後に、SCTP部分信頼性拡張[RFC3758]は、選択的再送信を停止し、受信機は、影響を受けるすべてのストリーム上のメッセージをキューに入れられた送達を可能にする未処理のメッセージを、放棄する送信者を可能にします。いくつかのアプリケーションに適していますが、このサービスモデルは、異なっており、ややUDPの完全信頼性の低いサービス、より少ない柔軟性をアプリケーションに提供します。
One could suggest adding support for alternative congestion control mechanisms as an option to SCTP, and adding a fully-unreliable variant that does not include the mechanisms for multiple streams. We would argue against this. SCTP is well-suited for applications that desire limited retransmission with multistream or multihoming support. Adding support for fully-unreliable variants, multiple congestion control profiles, and reduced single-stream headers would risk introducing unforeseen interactions and make further modifications ever more difficult. We have chosen instead to implement a minimal protocol, designed for fully-unreliable datagram service, that provides only end-to-end congestion control and any other mechanisms that cannot be provided in a higher layer.
一つは、SCTPのオプションとして代替輻輳制御メカニズムのサポートを追加し、複数のストリームのためのメカニズムが含まれていません完全に信頼できないバリアントを追加することをお勧めできます。私たちは、この反対主張するだろう。 SCTPはマルチストリームやマルチホーミングをサポートして限られた再送信を希望するアプリケーションに最適です。完全に信頼できない変異体、複数の輻輳制御プロファイル、および減少単一ストリームヘッダのサポートを追加すると、予期せぬ相互作用を導入するリスクと、さらに修正これまで以上に困難になるだろう。我々は、エンドツーエンドの輻輳制御及び上位層に提供することができない他の任意のメカニズムを提供完全に信頼性のないデータグラムサービスのために設計された最小限のプロトコルを実装する代わりに選択しました。
Several of our target applications currently use RTP layered above UDP to transfer their data. Why not modify RTP to provide end-to-end congestion control?
私たちのターゲットアプリケーションのいくつかは、現在、RTPが自分のデータを転送するためにUDPの上に重ねます。なぜ、エンドツーエンドの輻輳制御を提供するために、RTPを変更していませんか？
When RTP lives above UDP, modifying it to support congestion control might create some of the problems described in Section 3.1. In particular, user-level RTP implementations would want access to ECN bits in UDP datagrams. It might be difficult or undesirable to allow that access for RTP, but not for other user-level programs.
RTPはUDPの上に住んでいる場合は、3.1節で説明した問題のいくつかを作成することができます輻輳制御をサポートするためにそれを修正します。具体的には、ユーザーレベルのRTP実装は、UDPデータグラム内のECNビットへのアクセスを望みます。 RTPのためのアクセスを許可することは困難または望ましくないことではなく、他のユーザレベルのプログラムのためかもしれません。
Kernel implementations of RTP would not suffer from this problem. In the end, the argument against modifying RTP is the same as that against modifying SCTP: Some applications, such as the export of flow information from routers, need congestion control but don't need much of RTP's functionality. From these applications' point of view, RTP would induce unnecessary overhead. Again, we would argue for a clean and minimal protocol focused on end-to-end congestion control.
RTPのカーネルの実装は、この問題に苦しむないでしょう。最後に、RTPを修正に対する引数は、SCTPの変更に対するものと同じである：ルーターからのフロー情報のエクスポートなどの一部のアプリケーションでは、輻輳制御を必要とするが、RTPの機能の多くを必要としません。ビューのこれらのアプリケーションの観点から、RTPは、不必要なオーバーヘッドを誘導します。ここでも、我々は、エンドツーエンドの輻輳制御に焦点を当てた、清潔で最低限のプロトコルのために主張するだろう。
RTP would commonly be used as a layer above any new transport protocol, however. The design of that new transport protocol should take this into account, either by avoiding undue duplication of information available in the RTP header, or by suggesting modifications to RTP, such as a reduced RTP header that removes any fields redundant with the new protocol's headers.
RTPは、一般的にしかし、新しいトランスポートプロトコル上の層として使用されるであろう。その新しいトランスポートプロトコルの設計は、RTPヘッダ内の利用可能な情報の過度の重複を回避することによって、又はそのような新しいプロトコルのヘッダを持つ冗長任意のフィールドを除去低減RTPヘッダとしてRTPへの変更を示唆いずれかによって、このことを考慮すべきです。
In the first half of this document, we have argued for providing congestion control at the transport layer as an alternative to UDP, instead of relying on congestion control supplied only above or below UDP. In this section, we have examined the possibilities of modifying SCTP, modifying TCP, and designing a new transport protocol. In large part because of the requirement for unreliable transport, and for accommodating TFRC as well as TCP-like congestion control, we have concluded that modifications of SCTP or TCP are not the best answer and that a new transport protocol is needed. Thus, we have argued for the need for a new transport protocol that offers unreliable delivery, accommodates TFRC as well as TCP-like congestion control, accommodates the use of ECN, and requires minimal overhead in packet size and in the state and CPU processing required at the data receiver.
本書の前半では、我々は、UDPの代替として、トランスポート層で輻輳制御を提供するのではなく、唯一のUDP上または下に供給輻輳制御に頼るために主張してきました。このセクションでは、我々は、SCTPを変更するTCPを変更し、新しいトランスポートプロトコルを設計する可能性を検討しました。理由は信頼性の低い輸送のための要件の大部分では、とTFRCだけでなく、TCPのような輻輳制御を収容するために、我々は、SCTPまたはTCPの変更が最良の答えではないことや、新たなトランスポートプロトコルが必要であると結論しています。したがって、我々は信頼性のない配信を提供する新しいトランスポートプロトコルの必要性を主張してきた、TFRCだけでなく、TCPのような輻輳制御を収納ECNの使用を収容し、パケットサイズで、必要な状態とCPU処理で最小のオーバーヘッドが必要ですデータ受信時。
The goal of this work is to provide general congestion control mechanisms that will actually be used by many of the applications that currently use UDP. This may include applications that are perfectly happy without end-to-end congestion control. Several of our design requirements follow from a desire to design and deploy a congestion-controlled protocol that is actually attractive to these "reluctant" applications. These design requirements include a choice between different forms of congestion control, moderate overhead in the size of the packet header, and the use of Explicit Congestion Notification (ECN) and the ECN nonce [RFC3540], which provide positive benefit to the application itself.
この作業の目的は、実際には現在、UDPを使用するアプリケーションの多くで使用される一般的な輻輳制御機構を提供することです。これは、エンドツーエンドの輻輳制御せずに完全に満足しているアプリケーションを含むことができます。私たちの設計要件のいくつかは、これらの「消極的」なアプリケーションに実際に魅力的である輻輳制御プロトコルを設計し、展開したいという願望から従ってください。これらの設計要件は、アプリケーション自体に正の利益を提供する輻輳制御、パケットヘッダのサイズが適度なオーバーヘッドの異なる形態間の選択、および明示的輻輳通知（ECN）とECNナンス[RFC3540]の使用を含みます。
There will always be a few flows that are resistant to the use of end-to-end congestion control, preferring an environment where end-to-end congestion control is used by everyone else, but not by themselves. There has been substantial agreement [RFC2309, FF99] that in order to maintain the continued use of end-to-end congestion control, router mechanisms are needed to detect and penalize uncontrolled high-bandwidth flows in times of high congestion; these router mechanisms are colloquially known as "penalty boxes". However, before undertaking a concerted effort toward the deployment of penalty boxes in the Internet, it seems reasonable, and more effective, to first make a concerted effort to make end-to-end congestion control easily available to applications currently using UDP.
常にではなく、自分自身で、エンドツーエンドの輻輳制御を皆で使用された環境を好む、エンドツーエンドの輻輳制御の使用に耐性のあるいくつかの流れがあります。実質的な合意がなされてきた[RFC2309、FF99]エンドツーエンドの輻輳制御の継続的な使用を維持するために、ルータ機構を検出し、制御されない高帯域幅、高輻輳時に流れる不利に必要とされます。これらのルータのメカニズムは、口語的に「ペナルティボックス」として知られています。しかし、インターネットでのペナルティボックスの展開に向け協調努力に着手する前に、最初に、現在UDPを使用するアプリケーションへのエンドツーエンドの輻輳制御が簡単に利用できるようにする協調努力をするために、合理的、かつより効果的なようです。
This section mentions some additional design considerations that should be considered in designing a new transport protocol.
このセクションでは、新しいトランスポートプロトコルを設計する際に考慮すべきいくつかの追加の設計上の考慮事項に言及しています。
o Mobility: Mechanisms for multihoming and mobility are one area of additional functionality that cannot necessarily be layered cleanly and effectively on top of a transport protocol. Thus, one outstanding design decision with any new transport protocol concerns whether to incorporate mechanisms for multihoming and mobility into the protocol itself. The current version of DCCP [RFC4340] includes no multihoming or mobility support.
Oモビリティ：マルチホーミングとモビリティのためのメカニズムは必ずしもトランスポートプロトコルの上にきれいにかつ効果的に重ねることができない追加機能の一つの領域です。このように、プロトコル自体にマルチホーミングとモビリティのためのメカニズムを組み込むかどうかを任意の新しいトランスポートプロトコルの懸念を持つ1つの優れたデザインの決定。 DCCP [RFC4340]の現在のバージョンはマルチホーミングやモビリティサポートが含まれていません。
o Defense against DoS attacks and spoofing: A reliable handshake for connection setup and teardown offers protection against DoS and spoofing attacks. Mechanisms allowing a server to avoid holding any state for unacknowledged connection attempts or already-finished connections offer additional protection against DoS attacks. Thus, in designing a new transport protocol, even one designed to provide minimal functionality, the requirements for providing defense against DoS attacks and spoofing need to be considered.
O DoS攻撃やスプーフィングに対する防御：接続設定およびティアダウンのための信頼性の高いハンドシェイクがDoS攻撃やスプーフィング攻撃に対する保護を提供しています。サーバが未確認の接続試行または既に終了した接続のための任意の状態を保持しないようすることができますメカニズムは、DoS攻撃に対する追加の保護を提供します。このように、新しいトランスポートプロトコル、最小限の機能を提供するように設計しても1を設計する際に、DoS攻撃やスプーフィングに対する防御を提供するための要件を考慮する必要があります。
o Interoperation with RTP: As Section 3.3.3 describes, attention should be paid to any necessary or desirable changes in RTP when it is used over the new protocol, such as reduced RTP headers.
RTPとの相互運用（O）それは新しいプロトコル上で使用されるとき、セクション3.3.3に記載したように、注目は、そのような減少RTPヘッダとして、RTPに必要なまたは望ましい変更に支払わなければなりません。
o API: Some functionality required by the protocol, or useful for applications using the protocol, may require the definition of new API mechanisms. Examples include allowing applications to decide what information to put in a packet at transmission time, and providing applications with some information about packet sequence numbers.
O API：いくつかのプロトコルによって必要とされる機能、またはプロトコルを使用してアプリケーションに役立ち、新しいAPIメカニズムの定義が必要な場合があります。例としては、アプリケーションが、送信時にパケットに置くためにどのような情報を決定することができ、およびパケットシーケンス番号に関するいくつかの情報をアプリケーションに提供することを含みます。
o Interactions with NATs and firewalls: NATs and firewalls don't interact well with UDP, with its lack of explicit flow setup and teardown and, in practice, the lack of well-known ports for many UDP applications. Some of these issues are application specific; others should be addressed by the transport protocol itself.
NATのファイアウォールとの相互作用○：NATのファイアウォールは、その明示的な流れのセットアップとティアダウンの欠如と、実際には、多くのUDPアプリケーションのためのよく知られたポートの欠如と、UDPとよく相互作用しません。これらの問題のいくつかは、アプリケーション固有のものです。他の人は、トランスポートプロトコル自体によって対処されなければなりません。
o Consider general experiences with unicast transport: A Requirements for Unicast Transport/Sessions (RUTS) BOF was held at the IETF meeting in December 1998, with the goal of understanding the requirements of applications whose needs were not met by TCP [RUTS]. Not all of those unmet needs are relevant to or appropriate for a unicast, congestion-controlled, unreliable flow of datagrams designed for long-lived transfers. Some are, however, and any new protocol should address those needs and other requirements derived from the community's experience. We believe that this document addresses the requirements relevant to our problem area that were brought up at the RUTS BOF.
Oユニキャスト輸送との一般的な経験を考えてみましょう：ユニキャスト交通/セッションの要件（わだち）がBOFニーズTCP [轍]で満たされなかったアプリケーションの要件を理解することを目標に、1998年12月にIETF会議で開催されました。いないすべてのそれらのアンメットニーズのはに関連するか、長寿命の転送のために設計されたデータグラムのユニキャスト、輻輳制御、信頼性の低いフローに適しています。いくつかは、しかし、であり、任意の新しいプロトコルは、これらのニーズとコミュニティの経験から得られる他の要件に対処すべきです。私たちは、この文書は轍BOFで育った私たちの問題領域に関連する要件に対応することを考えています。
Up until now, this document has discussed the transport and congestion control requirements of applications that generate long-lived, large flows of unreliable datagrams. This section discusses briefly the transport needs of another class of applications, those of request/response transfers where the response might be a small number of packets, with preferences that include both reliable delivery and a minimum of state maintained at the ends. The reliable delivery could be accomplished, for example, by having the receiver re-query when one or more of the packets in the response is lost. This is a class of applications whose needs are not well-met by either UDP or by TCP.
今までは、この文書では、信頼性のないデータグラムの長寿命、大きな流れを生成するアプリケーションの輸送及び輻輳制御要件を検討しています。このセクションでは、簡単にアプリケーション、応答が信頼できる配信と端部で保持状態の最小値の両方を含むプリファレンスと、パケットの数が少ないかもしれない要求/応答転送のそれらの別のクラスの輸送の必要性を論じています。信頼性の高い配信は、例えば、応答パケットの1つ以上が失われた場合、受信機の再クエリを有することによって、達成することができます。これは、ニーズUDPのいずれかによって、またはTCPによく満たされていないアプリケーションのクラスです。
Although there is a legitimate need for a transport protocol for such short-lived reliable flows of such request/response applications, we believe that the overlap with the requirements of DCCP is almost non-existent and that DCCP should not be designed to meet the needs of these request/response applications. Areas of non-compatible requirements include the following:
そのような要求/応答アプリケーションのような短い寿命信頼性の高いフローのトランスポートプロトコルのための正当な必要性があるが、我々はDCCPの要求事項との重複がほとんど存在であることやDCCPがニーズを満たすように設計されるべきではないと信じていますこれらの要求/応答アプリケーションの。非互換性の要件のエリアには、次のものがあります。
o Reliability: DCCP applications don't need reliability (and long-lived applications that do require reliability are well-suited to TCP or SCTP). In contrast, these short-lived request/response applications do require reliability (possibly client-driven reliability in the form of requesting missing segments of a response).
信頼性○：DCCPアプリケーションは、信頼性を必要としない（と信頼性を必要としない、長寿命のアプリケーションは、TCPまたはSCTPに適しています）。これとは対照的に、これらの短命要求/応答アプリケーションは、信頼性（応答の欠落しているセグメントを要求する形で、おそらくクライアント主導の信頼性）が必要です。
o Connection setup and teardown: Because DCCP is aimed at flows whose duration is often unknown in advance, it addresses interactions with NATs and firewalls by having explicit handshakes for setup and teardown. In contrast, the short-lived request/response applications know the transfer length in advance, but cannot tolerate the additional delay of a handshake for flow setup. Thus, mechanisms for interacting with NATs and firewalls are likely to be completely different for the two sets of applications.
O接続のセットアップとティアダウン：DCCPは持続時間が事前にしばしば不明であるフローを目指しているので、それはセットアップとティアダウンのための明示的なハンドシェイクを持つことにより、NATのファイアウォールとの相互作用に対応しています。これとは対照的に、短命の要求/応答アプリケーションは、事前に転送長を知っているが、フロー設定のためのハンドシェイクの追加の遅延を許容することはできません。したがって、NATのファイアウォールと対話するためのメカニズムは、アプリケーションの二組のための完全に異なる可能性が高いです。
o Congestion control mechanisms: The styles of congestion control mechanisms and negotiations of congestion control features are heavily dependent on the flow duration. In addition, the preference of the request/response applications for a stateless server strongly impacts the congestion control choices. Thus, DCCP and the short-lived request/response applications have rather different requirements both for congestion control mechanisms and for negotiation procedures.
O輻輳制御メカニズム：輻輳制御機構のスタイルと輻輳制御機能の交渉は流れの期間に大きく依存しています。また、ステートレスなサーバの要求/応答アプリケーションの好みが強く影響輻輳制御の選択肢。したがって、DCCPおよび短命の要求/応答アプリケーションは、輻輳制御機構および交渉手順のための両方ではなく、異なる要件を有します。
Our problem statement has discussed the need for implementing congestion control for unreliable flows. Additional problems concern the need for low overhead, the problems of firewall traversal, and the need for reliable parameter negotiation. Our consideration of the problem statement has resulted in the following general recommendations:
私たちの問題文は、信頼性の低いフローの輻輳制御を実装するための必要性を議論しました。追加の問題は、低オーバーヘッドの必要性、ファイアウォールトラバーサルの問題、および信頼性の高いパラメータネゴシエーションの必要性を懸念します。問題文の私達の考慮事項は、以下の一般的な推奨事項をもたらしました：
o A unicast transport protocol for unreliable datagrams should be developed, including mandatory, built-in congestion control, explicit connection setup and teardown, reliable feature negotiation, and reliable congestion feedback.
O信頼性のないデータグラムのためのユニキャストトランスポートプロトコルは必須、内蔵の輻輳制御、明示的な接続のセットアップとティアダウン、信頼性の高い機能のネゴシエーション、および信頼性の高い輻輳フィードバックを含め、開発されるべきです。
o The protocol must provide a set of congestion control mechanisms from which the application may choose. These mechanisms should include, at minimum, TCP-like congestion control and a more slowly-responding congestion control such as TFRC.
Oプロトコルは、アプリケーションが選択することができる、そこから輻輳制御機構のセットを提供しなければなりません。これらのメカニズムは最小、TCPのような輻輳制御や、TFRCなどのよりゆっくりと応答の輻輳制御で、含まれるべきです。
o Important features of the connection, such as the congestion control mechanism in use, should be reliably negotiated by both endpoints.
このような使用の輻輳制御機構としての接続の重要な特徴、O、確実に両方のエンドポイントによって交渉されるべきです。
o Support for ECN should be included. (Applications could still make the decision not to use ECN for a particular session.)
O ECNのサポートが含まれなければなりません。 （アプリケーションは、まだ特定のセッションのためにECNを使用しない決定を行うことができます。）
o The overhead must be low, in terms of both packet size and protocol complexity.
Oオーバーヘッドは、パケットサイズおよびプロトコルの複雑さの両方の点で、低くなければなりません。
o Some DoS protection for servers must be included. In particular, servers can make themselves resistant to spoofed connection attacks ("SYN floods").
OサーバのためのいくつかのDoS保護が含まれている必要があります。具体的には、サーバは、偽装された接続の攻撃（「SYNフラッド」）に自身が耐性を作ることができます。
o Connection setup and teardown must use explicit handshakes, facilitating transmission through stateful firewalls.
O接続のセットアップとティアダウンは、ステートフルファイアウォール経由で伝送を促進する、明示的なハンドシェイクを使用する必要があります。
In 2002, there was judged to be a consensus about the need for a new unicast transport protocol for unreliable datagrams, and the next step was then the consideration of more detailed architectural issues.
2002年には、そこに信頼性のないデータグラムのための新たなユニキャストトランスポートプロトコルの必要性についてのコンセンサスであると判断し、次のステップは、より詳細なアーキテクチャの問題を考慮しました。
There are no security considerations for this document. It does discuss a number of security issues in the course of problem analysis, such as DoS resistance and firewall traversal. The security considerations for DCCP are discussed separately in [RFC4340].
この文書に関するセキュリティ上の考慮事項はありません。このようなDoS攻撃耐性およびファイアウォールトラバーサルなど問題分析の過程で、セキュリティ問題の数を、議論しません。 DCCPのためのセキュリティの考慮事項は、[RFC4340]で別々に議論されています。
We would like to thank Spencer Dawkins, Jiten Goel, Jeff Hammond, Lars-Erik Jonsson, John Loughney, Michael Mealling, and Rik Wade for feedback on earlier versions of this document. We would also like to thank members of the Transport Area Working Group and of the DCCP Working Group for discussions of these issues.
私たちは、この文書の以前のバージョンへのフィードバックのためにスペンサードーキンス辞典Goelさん、ジェフ・ハモンド、ラース・エリックジョンソン、ジョンLoughney、マイケル・メオーリング、とのRikウェイドに感謝したいと思います。また、これらの問題の議論のための交通地域作業部会のとDCCP作業部会のメンバーに感謝したいと思います。
Informative References
参考文献
[BRS99] Balakrishnan, H., Rahul, H., and S. Seshan, "An Integrated Congestion Management Architecture for Internet Hosts", SIGCOMM, Sept. 1999.
[BRS99]バラクリシュナン、H.、ラーフル、H.、およびS. Seshan、 "インターネットホストのための統合された輻輳管理アーキテクチャ"、SIGCOMM、1999年9月。
[FF99] Floyd, S. and K. Fall, "Promoting the Use of End-to-End Congestion Control in the Internet", IEEE/ACM Transactions on Networking, August 1999.
[FF99]フロイド、S.とK.秋、「インターネットにおけるエンドツーエンドの輻輳制御の利用促進」、ネットワーキング、1999年8月にIEEE / ACM取引。
[PF01] Padhye, J. and S. Floyd, "Identifying the TCP Behavior of Web Servers", SIGCOMM 2001.
[PF01] Padhye、J.及びS.フロイド、 "WebサーバーのTCPの動作の識別"、SIGCOMM 2001。
[RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J., and L. Zhang, "Recommendations on Queue Management and Congestion Avoidance in the Internet", RFC 2309, April 1998.
[RFC2309]ブレーデン、B.、クラーク、D.、クロウクロフト、J.、デイビー、B.、デアリング、S.、Estrin、D.、フロイド、S.、ヤコブソン、V.、Minshall、G.、ヤマウズラ、 C.、ピーターソン、L.、ラマクリシュナン、K.、Shenker、S.、Wroclawski、J.、およびL.チャン、 "インターネットの待ち行列管理と輻輳回避の推薦"、RFC 2309、1998年4月。
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2326] SchulzrinneとH.とラオとA.、およびR. Lanphier、 "リアルタイムのストリーミングプロトコル（RTSP）"、RFC 2326、1998年4月。
[RFC2525] Paxson, V., Allman, M., Dawson, S., Fenner, W., Griner, J., Heavens, I., Lahey, K., Semke, J., and B. Volz, "Known TCP Implementation Problems", RFC 2525, March 1999.
[RFC2525]パクソン、V.、オールマン、M.、ドーソン、S.、フェナー、W.、Griner、J.、天、I.、レイヒー、K.、Semke、J.、およびB.フォルツ、「既知TCPの実装の問題」、RFC 2525、1999年3月。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[RFC2914]フロイド、S.、 "輻輳制御の原理"、BCP 41、RFC 2914、2000年9月。
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[RFC2960]スチュワート、R.、謝、Q.、Morneault、K.、シャープ、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カラ、M.、チャン、L.、およびV 。パクソン、 "ストリーム制御伝送プロトコル"、RFC 2960、2000年10月。
[RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager", RFC 3124, June 2001.
[RFC3124]バラクリシュナン、H.とS. Seshan、 "輻輳管理"、RFC 3124、2001年6月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
"IPに明示的輻輳通知の添加（ECN）" [RFC3168]ラマクリシュナン、K.、フロイド、S.、およびD.ブラック、RFC 3168、2001年9月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 3448, January 2003.
[RFC3448]ハンドレー、M.、フロイド、S.、Padhye、J.、およびJ.ウィトマー、 "TCPフレンドリーレート制御（TFRC）：プロトコル仕様"、RFC 3448、2003年1月。
[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit Congestion Notification (ECN) Signaling with Nonces", RFC 3540, June 2003.
[RFC3540]春、N.、Wetherall、D.、およびD.イーリー、 "ロバスト明示的輻輳通知（ECN）ナンスとシグナリング"、RFC 3540、2003年6月。
[RFC3714] Floyd, S. and J. Kempf, "IAB Concerns Regarding Congestion Control for Voice Traffic in the Internet", RFC 3714, March 2004.
[RFC3714]フロイド、S.とJ.ケンプ、「インターネットで音声トラフィックのための輻輳制御に関するIAB心配」、RFC 3714、2004年3月。
[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, May 2004.
[RFC3758]スチュワート、R.、Ramalho、M.、謝、Q.、Tuexen、M.、およびP.コンラッド、 "ストリーム制御伝送プロトコル（SCTP）部分的な信頼性拡張"、RFC 3758、2004年5月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340]コーラー、E.、ハンドリー、M.、およびS.フロイド、 "データグラム輻輳制御プロトコル（DCCP）"、RFC 4340、2006年3月。
[RUTS] Requirements for Unicast Transport/Sessions (RUTS) BOF, Dec. 7, 1998. URL "http://www.ietf.org/proceedings/98dec/43rd-ietf-98dec-142.html".
【轍]ユニキャストトランスポート/セッションの要件（わだち）BOF、12月7日、1998年URL "http://www.ietf.org/proceedings/98dec/43rd-ietf-98dec-142.html"。
Authors' Addresses
著者のアドレス
Sally Floyd ICSI Center for Internet Research (ICIR), International Computer Science Institute, 1947 Center Street, Suite 600 Berkeley, CA 94704 USA
インターネットリサーチのためのサリーフロイドICSIセンター（ICIR）、国際コンピュータサイエンス研究所、1947センターストリート、スイート600バークレー、CA 94704 USA
EMail: floyd@icir.org
メールアドレス：floyd@icir.org
Mark Handley Department of Computer Science University College London Gower Street London WC1E 6BT UK
コンピュータサイエンス大学ロンドンガウアーストリートロンドンWC1E 6BT英国のマーク・ハンドリー部門
EMail: M.Handley@cs.ucl.ac.uk
メールアドレス：M.Handley@cs.ucl.ac.uk
Eddie Kohler 4531C Boelter Hall UCLA Computer Science Department Los Angeles, CA 90095 USA
エディー・コーラー4531C BoelterホールUCLAコンピュータサイエンス学部ロサンゼルス、CA 90095 USA
EMail: kohler@cs.ucla.edu
メールアドレス：kohler@cs.ucla.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。