[要約] RFC 4336は、DCCP（Datagram Congestion Control Protocol）の問題声明をまとめたものです。DCCPの目的は、データグラムベースの通信における適切な輻輳制御を提供することです。
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)
データグラムの混雑制御プロトコル（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).
Copyright（c）The Internet Society（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.
歴史的に、インターネットユニキャストトラフィックの大部分は渋滞制御TCPを使用しており、UDPは残りの大部分を占めています。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.
このドキュメントは、そのようなプロトコルの問題ステートメントを提供します。プロトコルに必要なプロパティをリストし、それらのプロパティが必要な理由を説明します。新しいプロトコルが、ユニキャストデータグラムの信頼性の低いフローに輻輳制御をもたらすというより一般的な問題の最良のソリューションである理由を説明し、モビリティ、サービス拒否（DOS）攻撃とスプーフィング、RTPとの相互操作に対する防衛のための補助的要件について簡単に議論します。ネットワークアドレス翻訳者（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.
この質問にもたらすデザインの好みの1つは、クリーンで理解しやすく、低オーバーヘッドで、最小限のプロトコルを好むことです。このドキュメントで後で説明したように、これにより、輸送プロトコル自体で提供されるのではなく、信頼性やフォワードエラー補正（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.
このドキュメントは、データグラムの混雑制御プロトコル[RFC4340]であるDCCPの目標の形式化として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]のセクション5および[RFC3714]のセクション2を参照してください。）
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.
o 明示的な混雑通知（ECN）[RFC3168]の使用を交渉するための標準的なソリューションの欠如。信頼できないフローの使用。
o The lack of a choice of TCP-friendly congestion control mechanisms.
o TCPに優しい輻輳制御メカニズムの選択の欠如。
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.
o ファイアウォールの存在下でUDPベースのフローを使用してアプリケーションを展開することの難しさ。
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に適したTCP様渋滞制御ではなく、TCPに優しいレートコントロール（TFRC）[RFC3448]など、混雑制御アルゴリズムを使用する必要のある影響が含まれますが、これらに限定されません。（TFRCは、TCPとの長期的な公正帯域幅共有を維持しながら、TCPよりもスムーズに送信速度を調整する輻輳制御メカニズムとしてIETFで標準化されています[RFC3448]。）
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のデータストリームを送信しますが、適度に低い遅延を必要とするテレフォニーアプリケーションは、20ミリ秒ごとにパケットを送信し、各パケットに14個のデータバイトのみを送信する場合があります。さらに、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.
信頼できないデータグラムのフローを必要とするアプリケーションは、現在、リアルタイムストリーミングプロトコル（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を介したストリーミングメディアは望ましくなく、データを「拒絶」している間にプレイアウトを一時的に停止する必要があることがあります。テレフォニーアプリケーションにはこのオプションさえありません。
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.
o UDP上の輻輳制御。
o Congestion control below UDP.
o UDP以下の混雑制御。
o Congestion control at the transport layer in an alternative to UDP.
o UDPに代わる輸送層での混雑制御。
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.
1つの可能性は、アプリケーションレイヤー、または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.)
TCP実装[RFC2525、PF01]をデバッグする長い歴史により、エンドツーエンドの混雑制御を実装するのが難しくなります。下層層で塗布用に輻輳制御が提供されることは明らかに堅牢です。まれに、輻輳制御メカニズムがアプリケーション自体に実装される説得力のある理由があるかもしれませんが、これが一般的なケースであるとは考えていません。たとえば、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の上に輻輳制御を提供することには2番目の問題があります。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 NonCeの開発により、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ソケットは、アプリケーションがIPヘッダーのECNフィールドにECN対応トランスポート（ECT）コードポイントを設定する必要があるかどうかを指定できるようにする必要があります。
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 CodePointを設定した送信者が、送信金利を下げることにより、経験豊富な（CE）CodePointsに応答する必要があることです。したがって、ECT CodePointは、以下が保証されている場合にのみ、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
o CEコードポイントがルーターによって設定されている場合、受信IPレイヤーはCEステータスをUDPレイヤーに渡し、それをデータ受信機の受信アプリケーションに渡します。と
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 CodePointセットがあるパケットを受信すると、受信アプリケーションはデータ送信者の通知など、適切な輻輳制御アクションを実行します。
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コードポイントのアプリケーションをarbitrary意的に制御できるようにすることは、エンドを使用しながらECNを使用するアプリケーションがECNを使用する不必要な機会のように思えます。 - 端までの混雑制御。したがって、最初にルーターにポリシングメカニズムを展開するか、最初に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.
持続的な混雑の期間を扱うためのより微細なメカニズムがない場合、1つの可能性は、混雑期間中に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以下のレイヤーで信頼性の低いアプリケーションの混雑制御を提供することです。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.
2) UDPの下のレイヤーでのフィードバック：アプリケーションは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の下のうっ血マネージャーに伝えます。このアプローチは、セクション3.1で説明されているほとんどの問題に苦しんでいます。つまり、アプリケーションデザイナーは、パケット形式とパラメーターの交渉のために毎回ホイールを再発明すること、およびECN使用、ファイアウォール、および回避の問題に苦しんでいます。
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の下に追加のパケットヘッダーが必要です。このヘッダーがIPオプションでない限り（多くのIPv4ルーターに問題を引き起こす可能性が高い）、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の代替として使用される輸送プロトコルで輸送層で混雑制御を提供することであると確信しています。信頼性の低い輸送プロトコルでエンドツーエンドの混雑制御を提供することの1つの利点は、現在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.
次に、信頼性の低いアプリケーションで使用するためにTCPを適応させるか、ストリーム制御伝送プロトコル（SCTP）の信頼性の低いバリアントを使用するか、渋滞制御が組み込まれたRTPのバージョンを使用するか、新しい輸送プロトコルを設計するかどうかという問題が発生します。
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.
1つの選択肢は、信頼性のある配信を希望するアプリケーションのために、信頼性が上に階層化された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の重要性と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パケットの基本的な基礎構造と、それに続くデータ、サック情報などのチャンクが、複数のストリームに対応するという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.
2番目の懸念事項として、現在指定されている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は、MultiStreamまたはMultihomingサポートを使用した限定的な再送信を要求するアプリケーションに適しています。完全に使用できないバリアント、複数の混雑制御プロファイル、およびシングルストリームヘッダーの削減のサポートを追加すると、予期せぬ相互作用の導入が危険にさらされ、さらなる修正がさらに困難になります。代わりに、完全に信頼できないデータグラムサービス用に設計された最小限のプロトコルを実装することを選択しました。これは、エンドツーエンドの混雑制御と、より高い層で提供できない他のメカニズムのみを提供します。
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?
現在、ターゲットアプリケーションのいくつかは、現在、UDP上に階層化されたRTPを使用してデータを転送しています。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の使用に対応する新しい輸送プロトコルの必要性について主張しました。データレシーバーで。
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つの領域です。したがって、新しい輸送プロトコルを使用した未解決の設計決定の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攻撃に対する追加の保護を提供します。したがって、最小限の機能を提供するように設計された新しい輸送プロトコルを設計する際には、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.
o RTPとの相互操作：セクション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.
o 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 ユニキャスト輸送の一般的な経験を考慮してください。ユニキャスト輸送/セッション（RUTS）BOFの要件は、1998年12月のIETF会議で開催されました。これらの満たされていないニーズのすべてが、長寿命の転送用に設計されたユニキャスト、輻輳制御、信頼できないデータグラムのフローに関連する、または適切であるわけではありません。ただし、一部のプロトコルは、コミュニティの経験から派生したこれらのニーズやその他の要件に対処する必要があります。このドキュメントは、RUTS 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).
o 信頼性：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およびファイアウォールとの相互作用のメカニズムは、2つのアプリケーションセットで完全に異なる可能性があります。
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 floods」）に対して耐性を持たせることができます。
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.
スペンサー・ドーキンス、ジテン・ゴエル、ジェフ・ハモンド、ラース・エリック・ジョンソン、ジョン・ラフニー、マイケル・ミールリング、リック・ウェイドに感謝します。また、これらの問題の議論については、輸送エリアワーキンググループおよびDCCPワーキンググループのメンバーに感謝します。
Informative References
参考引用
[BRS99] Balakrishnan, H., Rahul, H., and S. Seshan, "An Integrated Congestion Management Architecture for Internet Hosts", SIGCOMM, Sept. 1999.
[BRS99] Balakrishnan、H.、Rahul、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] Floyd、S。およびK. Fall、「インターネットでのエンドツーエンドの混雑制御の使用を促進する」、1999年8月、ネットワーキングに関するIEEE/ACMトランザクション。
[PF01] Padhye, J. and S. Floyd, "Identifying the TCP Behavior of Web Servers", SIGCOMM 2001.
[PF01] Padhye、J。およびS. Floyd、「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] 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。、およびL. Zhang、「インターネットでのキュー管理と混雑回避に関する推奨事項」、RFC 2309、1998年4月。
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2326] Schulzrinne、H.、Rao、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] Paxson、V.、Allman、M.、Dawson、S.、Fenner、W.、Griner、J.、Heavens、I.、Lahey、K.、Semke、J。、およびB. Volz、 "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] Stewart、R.、Xie、Q.、Morneault、K.、Sharp、C.、Schwarzbauer、H.、Taylor、T.、Rytina、I.、Kalla、M.、Zhang、L。、およびV。Paxson、「Stream Control Transmission Protocol」、RFC 2960、2000年10月。
[RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager", RFC 3124, June 2001.
[RFC3124] Balakrishnan、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.
[RFC3168] Ramakrishnan、K.、Floyd、S。、およびD. Black、「IPへの明示的な混雑通知（ECN）の追加」、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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、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] Handley、M.、Floyd、S.、Padhye、J。、およびJ. Widmer、「TCP Friendry Rate Control（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] Spring、N.、Wetherall、D。、およびD. Ely、「Noncesによる堅牢な明示的な混雑通知（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] Floyd、S。およびJ. Kempf、「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] Stewart、R.、Ramalho、M.、Xie、Q.、Tuexen、M.、およびP. Conrad、「ストリーム制御伝送プロトコル（SCTP）部分信頼性拡張」、RFC 3758、2004年5月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340] Kohler、E.、Handley、M。、およびS. Floyd、「Datagramうっ血制御プロトコル（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".
[ruts]ユニキャスト輸送/セッション（ruts）bofの要件、1998年12月7日。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
Sally Floyd ICSI Center for Internet Research（ICIR）、International Computer Science Institute、1947 Center Street、Suite 600 Berkeley、CA 94704 USA
EMail: floyd@icir.org
Mark Handley Department of Computer Science University College London Gower Street London WC1E 6BT UK
マークハンドリーコンピュータサイエンス大学カレッジロンドンガワーストリートロンドンWC1E 6BT UK
EMail: M.Handley@cs.ucl.ac.uk
Eddie Kohler 4531C Boelter Hall UCLA Computer Science Department Los Angeles, CA 90095 USA
Eddie Kohler 4531C Boelter Hall UCLAコンピューターサイエンス部ロサンゼルス、カリフォルニア州90095 USA
EMail: kohler@cs.ucla.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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）によって提供されます。