Network Working Group G. Fairhurst
Request for Comments: 5634 A. Sathiaseelan
Category: Experimental University of Aberdeen
August 2009
Quick-Start for the Datagram Congestion Control Protocol (DCCP)
Abstract
抽象
This document specifies the use of the Quick-Start mechanism by the Datagram Congestion Control Protocol (DCCP). DCCP is a transport protocol that allows the transmission of congestion-controlled, unreliable datagrams. DCCP is intended for applications such as streaming media, Internet telephony, and online games. In DCCP, an application has a choice of congestion control mechanisms, each specified by a Congestion Control Identifier (CCID). This document specifies general procedures applicable to all DCCP CCIDs and specific procedures for the use of Quick-Start with DCCP CCID 2, CCID 3, and CCID 4. Quick-Start enables a DCCP sender to cooperate with Quick-Start routers along the end-to-end path to determine an allowed sending rate at the start of a connection and, at times, in the middle of a DCCP connection (e.g., after an idle or application-limited period). The present specification is provided for use in controlled environments, and not as a mechanism that would be intended or appropriate for ubiquitous deployment in the global Internet.
この文書では、データグラム輻輳制御プロトコル（DCCP）クイック・スタート・メカニズムを使用することを指定します。 DCCPは輻輳制御、信頼性のないデータグラムの送信を可能にするトランスポート・プロトコルです。 DCCPは、ストリーミングメディア、インターネット電話、およびオンラインゲームなどのアプリケーションを対象としています。 DCCPでは、アプリケーションは、輻輳制御メカニズム、輻輳制御識別子（CCID）によって指定された各々の選択肢を有しています。この文書は、すべてのDCCPのCCIDsとDCCP CCID 2、CCID 3、およびCCID 4とクイックスタートを使用するための具体的な手順に適用される一般的な手順を指定するクイックスタートは、エンドに沿っクイックスタートルータと協力するDCCP送信者を可能にします接続の開始時と、時間で、（アイドルまたはアプリケーション限られた期間の後に、例えば、）DCCP接続の途中で許容送信レートを決定するためのエンドツーエンドパス。本明細書は、制御された環境ではなく、グローバルなインターネットにおけるユビキタス配備のために意図又は適切であろうメカニズムとして使用するために提供されます。
Status of This Memo
このメモのステータス
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書（http://trustee.ietf.org/license-info）の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Terminology ................................................4
2. Quick-Start for DCCP ............................................5
2.1. Sending a Quick-Start Request for a DCCP Flow ..............5
2.1.1. The Quick-Start Interval ............................5
2.2. Receiving a Quick-Start Request for a DCCP Flow ............6
2.2.1. The Quick-Start Response Option .....................7
2.3. Receiving a Quick-Start Response ...........................8
2.3.1. The Quick-Start Mode ................................8
2.3.2. The Quick-Start Validation Phase ....................9
2.4. Procedure When No Response to a Quick-Start Request .......10
2.5. Procedure When a Packet Is Dropped While Using
Quick-Start ...............................................11
2.6. Interactions with Mobility and Signaled Path Changes ......11
2.7. Interactions with Path MTU Discovery ......................12
2.8. Interactions with Middleboxes .............................12
3. Mechanisms for Specific CCIDs ..................................13
3.1. Quick-Start for CCID 2 ....................................13
3.1.1. The Quick-Start Request for CCID 2 .................13
3.1.2. Sending a Quick-Start Response with CCID 2 .........13
3.1.3. Using the Quick-Start Response with CCID 2 .........13
3.1.4. Quick-Start Validation Phase for CCID 2 ............14
3.1.5. Reported Loss or Congestion While Using
Quick-Start ........................................14
3.1.6. CCID 2 Feedback Traffic on the Reverse Path ........15
3.2. Quick-Start for CCID 3 ....................................15
3.2.1. The Quick-Start Request for CCID 3 .................15
3.2.2. Sending a Quick-Start Response with CCID 3 .........15
3.2.3. Using the Quick-Start Response with CCID 3 .........16
3.2.4. Quick-Start Validation Phase for CCID 3 ............17
3.2.5. Reported Loss or Congestion during the
Quick-Start Mode or Validation Phase ...............17
3.2.6. CCID 3 Feedback Traffic on the Reverse Path ........18
3.3. Quick-Start for CCID 4 ....................................18
3.3.1. The Quick-Start Request for CCID 4 .................18
3.3.2. Sending a Quick-Start Response with CCID 4 .........18
3.3.3. Using the Quick-Start Response with CCID 4 .........18
3.3.4. Reported Loss or Congestion While Using
Quick-Start ........................................19
3.3.5. CCID 4 Feedback Traffic on the Reverse Path ........19
4. Discussion of Issues ...........................................19
4.1. Overrun and the Quick-Start Validation Phase ..............19
4.2. Experimental Status .......................................19
5. IANA Considerations ............................................20
6. Acknowledgments ................................................20
7. Security Considerations ........................................20
8. References .....................................................21
8.1. Normative References ......................................21
8.2. Informative References ....................................21
The Datagram Congestion Control Protocol (DCCP) [RFC4340] is a transport protocol for congestion-controlled, unreliable datagrams, intended for applications such as streaming media, Internet telephony, and online games.
データグラム輻輳制御プロトコル（DCCP）[RFC4340]は、このようなストリーミングメディア、インターネット電話、およびオンラインゲームなどのアプリケーションを対象とし輻輳制御、信頼性のないデータグラムのトランスポートプロトコルです。
In DCCP, an application has a choice of congestion control mechanisms, each specified by a Congestion Control Identifier (CCID) [RFC4340]. There are general procedures applicable to all DCCP CCIDs that are described in Section 2, and details that relate to how individual CCIDs should operate, which are described in Section 3. This separation of CCID-specific and DCCP general functions is in the spirit of the modular approach adopted by DCCP.
DCCPでは、アプリケーションは、輻輳制御メカニズム、輻輳制御識別子（CCID）[RFC4340]で指定されたそれぞれの選択肢を有しています。 CCID固有およびDCCP一般的な機能のこの分離は、の精神である項3に記載されている個々のCCIDsが動作する方法に関連するすべてのDCCPセクション2に記載されているのCCIDs、詳細に適用される一般的な手順は、ありますモジュラーアプローチはDCCPで採択されました。
Quick-Start [RFC4782] is an experimental mechanism for transport protocols specified for use in controlled environments. The current specification of this mechanism is not intended or appropriate for ubiquitous deployment in the global Internet.
クイックスタート[RFC4782]は制御された環境で使用するために指定されたトランスポートプロトコルのための実験的機構です。このメカニズムの現在の仕様は、意図またはグローバルなインターネットにおけるユビキタスの展開に適していません。
Quick-Start is designed for use between end hosts within the same network or on Internet paths that include IP routers. It works in cooperation with routers, allowing a sender to determine an allowed sending rate at the start and at times in the middle of a data transfer (e.g., after an idle or application-limited period).
クイックスタートは、同じネットワーク内またはIPルータを含め、インターネットパス上のエンドホスト間で使用するために設計されています。これは、（アイドルまたはアプリケーション限られた期間の後に、例えば）送信者は、データ転送の途中で開始時との時間で許容送信レートを決定することを可能にする、ルータと連携して動作します。
This document assumes the reader is familiar with RFC 4782 [RFC4782], which specifies the use of Quick-Start with IP and with TCP. Section 7 of RFC 4782 also provides guidelines for the use of Quick-Start
この文書では、読者がIPとし、TCPとクイックスタートの使用を指定し、RFC 4782 [RFC4782]、に精通している前提としています。 RFC 4782のセクション7も、クイックスタートを使用するためのガイドラインを提供
with other transport protocols, including DCCP. This document provides answers to some of the issues that were raised by RFC 4782 and provides a definition of how Quick-Start must be used with DCCP.
DCCPを含む他のトランスポートプロトコル、と。この文書は、RFC 4782で上昇し、クイックスタートはDCCPで使用しなければならないかの定義を提供していた問題のいくつかに答えを提供します。
In using Quick-Start, the sending DCCP end host indicates the desired sending rate in bytes per second, using a Quick-Start option in the IP header of a DCCP packet. Each Quick-Start-capable router along the path could, in turn, either approve the requested rate, reduce the requested rate, or indicate that the Quick-Start Request is not approved.
クイックスタートを使用して、送信DCCPエンドホストはDCCPパケットのIPヘッダ内のクイックスタート・オプションを使用して、秒あたりのバイト数で、所望の送信速度を示しています。パスに沿って各クイックスタート対応ルータは、今度は、要求された割合を承認要求率を低下させる、またはクイックスタート要求が承認されていないことを示している可能性がありどちらか。
If the Quick-Start Request is approved (possibly with a reduced rate) by all the routers along the path, then the DCCP receiver returns an appropriate Quick-Start Response. On receipt of this, the sending end host can send at up to the approved rate for a period determined by the method specified for each DCCP CCID, and not exceeding three round-trip times. Subsequent transmissions will be governed by the default CCID congestion control mechanisms for the connection. If the Quick-Start Request is not approved, then the sender must use the default congestion control mechanisms.
クイックスタート要求を経路に沿った全てのルータによって（おそらく減少速度で）承認された場合、その後、DCCP受信機は、適切なクイックスタート応答を返します。これを受信すると、送信側ホストは、各DCCP CCIDのために指定された方法、および3往復時間を超えないことにより、定められた期間のために承認されたレートまでで送信することができます。後続の送信は、接続のデフォルトCCIDの輻輳制御メカニズムによって支配されます。クイックスタート要求が承認されない場合、送信者は、デフォルトの輻輳制御メカニズムを使用する必要があります。
DCCP receivers are not required to acknowledge individual packets (or pairs of segments) as in TCP. CCID 2 [RFC4341] allows much less frequent feedback. Rate-based protocols (e.g., TCP-Friendly Rate Control (TFRC) [RFC5348], CCID 3 [RFC4342]) have a different feedback mechanism than that of TCP. With rate-based protocols, feedback may be sent less frequently (e.g., once per Round-Trip Time (RTT)). In such cases, a sender using Quick-Start needs to implement a different mechanism to determine whether the Quick-Start sending rate has been sustained by the network. This introduces a new mechanism called the Quick-Start Validation Phase (Section 2.3).
DCCP受信機は、TCPのように個々のパケット（またはセグメントの対）を認識する必要はありません。 CCID 2 [RFC4341]ははるかに少ない頻繁なフィードバックを可能にします。レートベースのプロトコル（例えば、TCPフレンドリーレート制御（TFRC）[RFC5348]、CCID 3 [RFC4342]）はTCPとは異なるフィードバック機構を有しています。レートベースのプロトコルを用いて、フィードバック（例えば、一度ラウンドトリップ時間（RTT）あたり）より少ない頻度で送信されてもよいです。このような場合には、クイックスタートを使用して、送信者は、クイックスタート、送信速度は、ネットワークによって支えられているかどうかを判断するために、別のメカニズムを実装する必要があります。これは、クイックスタートの検証フェーズ（2.3節）と呼ばれる新しいメカニズムを導入しています。
In addition, this document defines two more general enhancements that refine the use of Quick-Start after a flow has started (expected to be more common in applications using DCCP). These are the Quick-Start Interval (Section 2.1.2), and the reaction to mobility triggers (Section 2.6).
また、この文書は、流れが（DCCPを使用するアプリケーションでより一般的であると予想される）を開始した後にクイックスタートの使用を改良、さらに2つの一般的な機能強化を定義します。これらは、クイックスタート間隔（2.1.2項）、およびモビリティのトリガーに反応（2.6節）です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
Unless otherwise specified, DCCP end hosts follow the procedures specified in Section 4 of [RFC4782], following the use specified for Quick-Start with TCP.
特に指定しない限り、DCCPエンドホストは、TCPとクイックスタートのために指定された使用後、[RFC4782]のセクション4で規定された手順に従ってください。
A DCCP sender MAY use a Quick-Start Request during the start of a connection, when the sender would prefer to have a larger initial rate than allowed by standard mechanisms (e.g., [RFC5348] or [RFC3390]).
送信者は、標準的な機構（例えば、[RFC5348]または[RFC3390]）によって許可さよりも大きい初期速度を有することを好む場合DCCP送信者は、接続の開始時にクイックスタート要求を使用するかもしれません。
A Quick-Start Request MAY also be used once a DCCP flow is connected (i.e., in the middle of a DCCP flow). In standard operation, DCCP CCIDs can constrain the sending rate (or window) to less than that desired (e.g., when an application increases the rate at which it wishes to send). A DCCP sender that has data to send after an idle period or application-limited period (i.e., where the sender has transmitted at less than the allowed sending rate) can send a Quick-Start Request using the procedures defined in Section 3.
DCCPフローは（すなわち、DCCPフローの途中に）接続されると、クイックスタート要求を使用してもよいです。標準動作において、DCCPのCCIDsが所望のものよりも少ないへの送信速度（またはウィンドウ）を拘束することができる（例えば、アプリケーションは、それが送信することを希望する速度を増加させる場合）。データを有するDCCP送信者は、アイドル期間またはアプリケーション限られた期間の後に送信する（すなわち、送信者が許容送信レート未満で送信した場合）、セクション3で定義された手順を使用して、クイックスタート要求を送信することができます。
Quick-Start Requests will be more effective if the Quick-Start Rate is not larger than necessary. Each requested Quick-Start Rate that has been approved, but was not fully utilized, takes away from the bandwidth pool maintained by Quick-Start routers that would be otherwise available for granting successive requests [RFC4782].
クイックスタートレートが必要以上に大きくない場合には、クイック・スタートの要求がより効果的になります。それぞれが承認されたクイックスタートレートを要求したが、十分に活用されていなかった、離れて連続したリクエスト[RFC4782]を付与するためにそれ以外の場合は利用できるようになるクイックスタートルータによって維持帯域幅プールから取ります。
In contrast to most TCP applications, many DCCP applications have the notion of a natural media rate that they wish to achieve. For example, during the initial connection, a host may request a Quick-Start Rate equal to the media rate of the application, appropriately increased to account for the size of packet headers. (Note that Quick-Start only provides a course-grain indication of the desired rate that is expected to be sent in the next RTT.)
ほとんどのTCPアプリケーションとは対照的に、多くのDCCPアプリケーションは、彼らが達成したい自然メディア率の概念を持っています。例えば、初期接続時に、ホストは、適切にパケットヘッダのサイズを考慮して増加し、アプリケーションのメディア速度に等しいクイックスタートレートを要求することができます。 （クイックスタートのみ次のRTTで送信されることが予想される所望の速度のコースグレインの指標を提供することに留意されたいです。）
When sending a Quick-Start Request, the DCCP sender SHOULD send the Quick-Start Request using a packet that requires an acknowledgement, such as a DCCP-Request, DCCP-Response, or DCCP-Data.
クイックスタートリクエストを送信する場合、DCCPの送信者は、このようなDCCP-要求、DCCP-応答、またはDCCP-データとして、承認を必要とするパケットを使用したクイック・スタート・リクエストを送るべきです。
Excessive use of the Quick-Start mechanism is undesirable. This document defines an enhancement to RFC 4782 to update the use of Quick-Start after a DCCP flow has started, by introducing the concept of the Quick-Start Interval. The Quick-Start Interval specifies a period of time during which a Quick-Start Request SHOULD NOT be sent. The Quick-Start Interval is measured from the time of transmission of the previous Quick-Start Request (Section 2.1). The Quick-Start Interval MAY be overridden as a result of a network path change (Section 2.6).
クイック・スタート・メカニズムの過度の使用は望ましくありません。この文書では、DCCPフローが開始された後にクイックスタート間隔の概念を導入することで、クイックスタートの使用を更新するために、RFC 4782に拡張機能を定義します。クイックスタート間隔は、クイック・スタート・リクエストが送信されてはならない期間を指定します。クイックスタート間隔は、前のクイックスタート要求（セクション2.1）の送信の時間から測定されます。クイックスタート間隔は、ネットワーク経路の変更（2.6節）の結果として上書きすることができます。
When a connection is established, the Quick-Start Interval is initialized to the Initial_QSI. The Initial_QSI MUST be at least 6 seconds (larger values are permitted). This value was chosen so that it is sufficiently large to prevent excessive router processing over typical Internet paths. Quick-Start routers that track per-flow state MAY penalize senders by suspending Quick-Start processing of flows that make Quick-Start Requests for the same flow with an interval less than 6 seconds.
接続が確立されると、クイックスタート間隔はInitial_QSIに初期化されます。 Initial_QSIは、少なくとも6秒（大きな値が許容されている）でなければなりません。この値は、典型的なインターネットパス上に過剰なルータ処理を防止するのに十分に大きくなるように選択しました。フローごとの状態が6秒未満の間隔と同じ流れのためのクイックスタート要求を行うフローのクイックスタート処理を懸濁して送信者を罰するMAY追跡クイックスタートルータ。
When the first Quick-Start Request is sent, the Quick-Start Interval is set to:
最初のクイック・スタート・リクエストが送信されると、クイックスタート間隔は次のように設定されています。
Quick-Start Interval = Initial_QSI;
クイックスタートインターバル= Initial_QSI。
After sending each subsequent Quick-Start Request, the Quick-Start Interval is then recalculated as:
後続の各クイックスタートリクエストを送信した後、クイックスタート間隔は次のように再計算されます。
Quick-Start Interval = max(Quick-Start Interval * 2, 4 * RTT);
クイックスタートインターバル= MAX（クイックスタート間隔* 2、4 * RTT）。
Each unsuccessful Quick-Start Request therefore results in the Quick-Start Interval being doubled (resulting in an exponential back-off). The maximum time the sender can back off is 64 seconds. When the back-off calculation results in a larger value, the sender MUST NOT send any further Quick-Start Requests for the remainder of the DCCP connection (i.e., the sender ceases to use Quick-Start).
各失敗したクイックスタート要求は、従って、クイックスタートインターバル（指数バックオフをもたらす）倍されることになります。送信者がオフにバックアップできる最大時間は64秒です。大きな値でバックオフ計算結果は、送信者がDCCP接続の残りの更なるクイックスタート要求を送信しない必要がある場合（すなわち、送信者は、クイックスタートを使用することを停止します）。
Whenever a Quick-Start Request is approved (at any rate), the Quick-Start Interval is reset to the Initial_QSI.
クイックスタート要求が（任意のレートで）承認されるたびに、クイックスタート間隔はInitial_QSIにリセットされます。
The procedure for processing a received Quick-Start Request is normatively defined in [RFC4782] and summarized in this paragraph. An end host that receives an IP packet containing a Quick-Start Request passes the Quick-Start Request, along with the value in the IP Time to Live (TTL) field, to the receiving DCCP layer. If the receiving host is willing to permit the Quick-Start Request, it SHOULD respond immediately by sending a packet that carries the Quick-Start Response option in the DCCP header of the corresponding feedback packet (e.g., using a DCCP-Ack packet or in a DCCP-DataAck packet).
受信クイックスタート要求を処理するための手順は、規範的に[RFC4782]で定義されており、この段落に要約されています。クイックスタート要求を含むIPパケットを受信したエンドホストが受信DCCP層に、（TTL）フィールドを生きてIP時間値と共に、クイックスタート要求を渡します。受信ホストはクイックスタート要求を可能にするのに気があるなら、それはDCCP-Ackパケットを使用して、対応するフィードバックパケット（例えば、のDCCPヘッダー内またはクイックスタート応答オプションを運ぶパケットを送信することにより即座に対応すべきですDCCP-DataAckパケット）。
The Rate Request field in the Quick-Start Response option is set to the received value of the Rate Request in the Quick-Start option or to a lower value if the DCCP receiver is only willing to allow a lower Rate Request. Where information is available (e.g., knowledge of the local Layer 2 interface speed), a Quick-Start receiver SHOULD verify that the received rate does not exceed its expected receive link capacity. The TTL Diff field in the Quick-Start Response is set to the difference between the received IP TTL value (Hop Limit field in IPv6) and the Quick-Start TTL value. The Quick-Start Nonce in the Response is set to the received value of the Quick-Start Nonce in the Quick-Start option (or IPv6 Header Extension).
DCCPの受信機は、低レート要求を可能にするだけで喜んであればレート要求フィールドにクイックスタート応答オプションは、クイックスタートオプションで以下の値にレート要求の受信した値に設定されています。情報が利用可能である場合（例えば、ローカルレイヤ2インターフェイス速度の知識）、クイックスタート受信機は、受信されたレートは、その受信期待リンク容量を超えていないことを確認してください。 TTL差分フィールドにクイックスタート応答が受信されたIP TTL値（IPv6におけるホップリミットフィールド）とクイックスタートTTL値との差に設定されています。応答したクイックスタートノンスは、クイックスタートオプション（またはIPv6ヘッダーの拡張）でのクイックスタートナンスの受信した値に設定されています。
The Quick-Start Response MUST NOT be resent if it is lost in the network [RFC4782]. Packet loss could be an indication of congestion on the return path; in which case, it is better not to approve the Quick-Start Request.
それはネットワーク[RFC4782]で失われた場合、クイックスタートレスポンスを再送してはなりません。パケット損失は、リターンパス上の輻輳の指標とすることができます。その場合には、クイックスタートリクエストを承認しない方がよいです。
If an end host receives an IP packet with a Quick-Start Request with a requested rate of zero, then this host SHOULD NOT send a Quick-Start Response [RFC4782].
エンドホストがゼロの要求率とクイックスタート要求にIPパケットを受信した場合、このホストは、クイックスタート応答[RFC4782]を送るべきではありません。
The Quick-Start Response message must be carried by the transport protocol using Quick-Start. This section defines a DCCP Header option used to carry the Quick-Start Response. This header option is REQUIRED for end hosts to utilize the Quick-Start mechanism with DCCP flows. The format resembles that defined for TCP [RFC4782].
クイックスタート応答メッセージは、クイックスタートを使用して、トランスポートプロトコルによって実行されなければなりません。このセクションでは、クイックスタートレスポンスを運ぶために使用DCCPヘッダーオプションを定義します。このヘッダ・オプションは、DCCPフロークイックスタート機構を利用するエンドホストのために必要とされます。フォーマットは、TCP [RFC4782]のために定義されていることに似ています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=45 | Length=8 | Resv. | Rate | TTL Diff |
| | | |Request| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Quick-Start Nonce | R |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. The Quick-Start Response Option
図1.クイックスタート応答オプション
The first byte of the Quick-Start Response option contains the option kind, identifying the DCCP option (45).
クイックスタート応答オプションの最初のバイトは、DCCPオプション（45）を識別する、オプションの種類が含まれています。
The second byte of the Quick-Start Response option contains the option length in bytes. The length field MUST be set to 8 bytes.
クイックスタート応答オプションの2番目のバイトは、バイト単位のオプションの長さが含まれています。長さフィールドは、8バイトに設定しなければなりません。
The third byte of the Quick-Start Response option contains a four-bit Reserved field, and the four-bit allowed Rate Request, formatted as in the IP Quick-Start Rate Request option [RFC4782].
クイックスタート応答オプションの3番目のバイトは、IPクイックスタートレート要求オプション[RFC4782]のようにフォーマットされた4ビットの予約フィールド、および4ビットの許可レート要求が含まれています。
The fourth byte of the DCCP Quick-Start Response option contains the TTL Diff. The TTL Diff contains the difference between the IP TTL and Quick-Start TTL fields in the received Quick-Start Request packet, as calculated in [RFC4782].
DCCPクイックスタート応答オプションの4番目のバイトは、TTL差分が含まれています。 TTL差分は、[RFC4782]で計算して、受信したクイックスタート要求パケットにIP TTLとクイックスタートTTLフィールドとの間の差を含んでいます。
Bytes 5-8 of the DCCP option contain the 30-bit Quick-Start Nonce and a 2-bit Reserved field [RFC4782].
DCCPオプションのバイト5-8は、30ビットのクイックスタートノンスと2ビットの予約フィールド[RFC4782]を含んでいます。
On reception of a Quick-Start Response packet, the sender MUST report the approved rate, by sending a Quick-Start Report of Approved Rate [RFC4782]. This report includes the Rate Report field set to the Approved Rate, and the QS Nonce set to the QS Nonce value sent in the Quick-Start Request.
クイックスタート応答パケットを受信すると、送信者が承認レートのクイックスタートレポート[RFC4782]を送信することにより、承認率を報告しなければなりません。このレポートは、承認されたレートに設定レートレポートのフィールドを含み、QS nonceがクイックスタート要求で送信されたQS Nonceの値に設定します。
The Quick-Start Report of Approved Rate is sent as an IPv4 option or IPv6 header extension using the first Quick-Start Packet or sent as an option using a DCCP control packet if there are no DCCP-Data packets pending transmission.
承認率のクイックスタートレポートは、第一クイックスタートパケットを用いたIPv4オプションまたはIPv6ヘッダの拡張として送信又は送信を保留中のDCCP - データパケットがない場合DCCP制御パケットを使用して、オプションとして送信されます。
The Quick-Start Interval is also reset (as described in Section 2.1.1).
（2.1.1項で説明したように）クイックスタート間隔もリセットされます。
Reception of a Quick-Start Response packet that approves a rate higher than the current rate results in the sender entering the Quick-Start Mode.
クイックスタートモードに入る送信者の現在のレートの結果よりも高い率承認クイックスタート応答パケットの受信。
While a sender is in the Quick-Start Mode, all sent packets are known as Quick-Start Packets [RFC4782]. The Quick-Start Packets MUST be sent at a rate not greater than the rate specified in the Quick-Start Response. The Quick-Start Mode continues for a period up to one RTT (shorter, if a feedback message arrives acknowledging the receipt of one or more Quick-Start Packets).
送信者がクイックスタートモード中は、すべての送信されたパケットは、クイックスタートパケット[RFC4782]として知られています。クイックスタートパケットは、クイックスタートレスポンスで指定されたレートよりも大きくないレートで送らなければなりません。 （フィードバックメッセージは、1つまたは複数のクイックスタートパケットの受信を確認到着した場合、短い）クイックスタートモードは、1 RTTまでの期間続きます。
The procedure following exit of the Quick-Start Mode is specified in the following paragraphs. Note that this behavior is CCID-specific and the details for each current CCID are described in Section 3.
クイック・スタート・モードの終了次の手順は、以下の段落で指定されています。この現象は、CCID固有であり、各電流CCIDの詳細はセクション3に記載されていることに留意されたいです。
After transmitting a set of Quick-Start Packets in the Quick-Start Mode (and providing that no loss or congestion is reported), the sender enters the Quick-Start Validation Phase. This phase persists for a period during which the sender seeks to affirm that the capacity used by the Quick-Start Packets did not introduce congestion. This phase is introduced, because unlike TCP, DCCP senders do not necessarily receive frequent feedback that would indicate the congestion state of the forward path.
クイックスタートモード（及び損失又は輻輳が報告されていないことを提供する）でクイックスタートパケットのセットを送信した後、送信者は、クイックスタート検証フェーズに入ります。このフェーズでは、送信者がクイックスタートパケットによって使用される容量は、混雑を導入していなかったことを肯定しようとする期間持続します。 TCPとは異なり、DCCP送信者は必ずしも、往路の輻輳状態を示すだろう頻繁なフィードバックを受けていないので、この相は、導入されます。
While in the Quick-Start Validation Phase, the sender is tentatively permitted to continue sending using the Quick-Start rate. This phase normally concludes when the sender receives feedback that includes an acknowledgment that all Quick-Start Packets were received.
クイックスタートの検証フェーズでいる間、送信者は、暫定的にクイック・スタート・レートを使用して送信を継続することが許されます。送信者は、すべてのクイックスタートパケットが受信されたことの確認を含んでフィードバックを受信したときに、この段階では、通常、終了します。
However, the duration of the Quick-Start Validation Phase MUST NOT exceed the Quick-Start Validation Time (a maximum of 2 RTTs). Implementations may set a timer (initialized to the Quick-Start Validation Time) to detect the end of this phase. There may be scope for optimization of timer resources in an implementation, since the Quick-Start Validation period temporarily enforces more strict monitoring of acknowledgements than normally used in a CCID (e.g., an implementation may consider using a common timer resource for Quick-Start Validation and a nofeedback timer).
しかし、クイックスタートの検証フェーズの期間は、クイックスタートの検証時間（2つのRTTの最大値）を超えてはなりません。実装は、このフェーズの終了を検出する（クイックスタート検証時刻に初期化）タイマーを設定することがあります。クイックスタートの検証期間が一時的に正常例えば、実装はクイックスタートの検証のための一般的なタイマリソースを使用して検討することができる（CCIDに使用されるよりも肯定応答のより厳格な監視を強制するので、実装のタイマリソースの最適化のための適用範囲があるかもしれませんそして、NOFEEDBACKタイマー）。
An example sequence of packet exchanges showing Quick-Start with DCCP is shown in Figure 2.
DCCPとクイックスタートを示すパケット交換のシーケンス例は、図2に示されています。
DCCP Sender DCCP Receiver
Quick-Start +----------------------------------------------+
Request/Response | Quick-Start Request --> |
| <-- Quick-Start Response |
| Quick-Start Approve --> |
+----------------------------------------------+
+----------------------------------------------+
Quick-Start | Quick-Start Packets --> |
Mode | Quick-Start Packets --> |
| <-- Feedback A from Receiver|
| (acknowledging first QS Packet)|
+----------------------------------------------+
+----------------------------------------------
Quick-Start | Packets --> |
Validation Phase | <-- Feedback B from Receiver|
| (acknowledging all QS Packets)|
+----------------------------------------------
+----------------------------------------------+
DCCP | Packets --> |
Congestion | <-- Feedback C from Receiver|
Control | |
Figure 2. The Quick-Start Mode and Validation Phase
クイックスタートモードと検証フェーズ2図
On conclusion of the Validation Phase (Feedback B in the above figure), the sender expects to receive assurance that it may safely use the current rate. A sender that completes the Quick-Start Validation Phase with no reported packet loss or congestion stops using the Quick-Start rate and continues to adjust its rate using the standard congestion control mechanisms. For example, if the DCCP sender was in slow-start prior to the Quick-Start Request, and no packets were lost or ECN-marked (Explicit Congestion Notification) since that time, then the sender continues in slow-start after exiting Quick-Start Mode until the sender sees a packet loss, or congestion is reported.
検証フェーズ（上図のフィードバックB）の終了時に、送信者は、それが安全に現在のレートを使用することができるという保証を受信することを期待します。無報告、パケットロスや輻輳とクイックスタートの検証フェーズを完了し、送信者は、クイック・スタート・レートを使用して停止し、標準の輻輳制御メカニズムを使用して、そのレートを調整し続けています。 DCCPの送信者はその時以来、スロースタートでクイックスタート要求に先立っていた、と何のパケットが失われていないか、ECN-マークされていた（明示的輻輳通知）例えば、もし、その送信者はQuick-を出た後、スロースタートで継続します送信者は、パケットロスを見て、または混雑が報告されるまでモードを開始します。
As in TCP, if a Quick-Start Request is dropped (i.e., the Request or Response is not delivered by the network) the DCCP sender MUST revert to the congestion control mechanisms it would have used if the Quick-Start Request had not been approved. The connection is not permitted to send a subsequent Quick-Start Request before expiry of the current Quick-Start Interval (Section 2.1.1).
クイックスタート要求がドロップされた場合は、TCPのように、DCCPの送信者は、クイックスタート要求が承認されていない場合、それは使用していただろう輻輳制御メカニズムに戻す必要があります（つまり、要求または応答は、ネットワークによって配信されません） 。接続は、現在のクイックスタート間隔（2.1.1項）の満了前に、後続のクイックスタート要求を送信することが許可されていません。
A lost or ECN-marked packet is an indication of potential network congestion. The behavior of a DCCP sender following a lost or ECN-marked Quick-Start Packet or a lost feedback packet is specific to a particular CCID (see Section 3).
紛失またはECN-マークされたパケットは、潜在的なネットワークの輻輳の指標です。紛失またはECN-マーククイックスタートパケットまたは失われたフィードバックパケットを、次のDCCP送信者の行動が特定のCCIDに固有である（セクション3を参照）。
The use of Quick-Start may assist end hosts in determining when it is appropriate to increase their rate following an explicitly signaled change of the network path.
クイックスタートの使用は、ネットワーク経路の明示的にシグナリングの変化以下の彼らの率を高めるために、適切なときに決定する際にエンドホストを助けることができます。
When an end host receives a signal from an upstream link/network notifying it of a path change, the change could simultaneously impact more than one flow, and may affect flows between multiple endpoints. Senders should avoid responding immediately, since this could result in unwanted synchronization of signaling messages, and control loops (e.g., a synchronized attempt to probe for a larger congestion window), which may negatively impact the performance of the network and transport sessions. In Quick-Start, this could increase the rate of Quick-Start Requests, possibly incurring additional router load, and may result in some requests not being granted. A sender must ensure this does not generate an excessive rate of Quick-Start Requests by using the method below:
エンドホストは、経路変更のことを通知する上流リンク/ネットワークからの信号を受信すると、変更は、同時に複数の流れに影響を与える可能性があり、複数のエンドポイントとの間のフローに影響を与えることができます。これは、シグナリングメッセージ、および制御ループの不要な同期をもたらす可能性があるので、送信者は、負ネットワーク及びトランスポートセッションのパフォーマンスに影響を与えることができる、（例えば、同期試行が大きな輻輳ウィンドウを探索するために）、直ちに応答を避けなければなりません。クイックスタートでは、これはおそらく、追加のルータの負荷を被る、クイックスタート要求のレートを上げることができ、および許可されていないいくつかの要求をもたらすことができます。送信者は、これは下の方法を使用してクイックスタート要求の過剰な割合を生成しないことを確認する必要があります。
A sender that has explicit information that the network path has changed (e.g., a mobile IP binding update [RFC3344], [RFC3775]) SHOULD reset the Quick-Start Interval to its initial value (specified in Section 2.1.1).
ネットワークパスが変更されたことを明示的な情報を有している送信者は（例えば、モバイルIPバインディング更新[RFC3344]、[RFC3775]）は（セクション2.1.1で指定された）初期値にクイックスタートインターバルをリセットする必要があります。
The sender MAY also send a Quick-Start Request to determine a new safe transmission rate, but must observe the following rules:
送信者はまた、新しい安全な伝送速度を決定するために、クイックスタートの要求を送信することができるが、以下の規則に従う必要があります。
- It MUST NOT send a Quick-Start Request within a period less than the initial Quick-Start Interval (Initial_QSI) since it previously sent a Quick-Start Request. That is, it must wait for at least a period of Initial_QSI after the previous request, before sending a new Quick-Start Request.
- それは、以前にクイック・スタート・リクエストを送ったので、それは最初のクイックスタート間隔（Initial_QSI）未満の期間内にクイックスタート要求を送ってはいけません。つまり、新しいクイックスタートリクエストを送信する前に、前回の要求の後Initial_QSIの少なくとも期間を待つ必要があり、です。
- If it has not sent a Quick-Start Request within the previous Initial_QSI period, it SHOULD defer sending a Quick-Start Request for a randomly chosen period between 0 and the Initial_QSI value in seconds. The random period should be statistically independent between different hosts and between different connections on the same host. This delay is to mitigate the effect on router load of synchronized responses by multiple connections in response to a path change that affects multiple connections.
- それは、以前のInitial_QSI期間内にクイックスタートリクエストを送信していない場合、それは0秒でInitial_QSI値の間でランダムに選ばれた期間のためのクイック・スタート・リクエストを送信延期すべきです。ランダム期間が異なるホスト間と同じホスト上の異なる接続間で統計的に独立であるべきです。この遅延は、複数の接続に影響し、パスの変更に応じて、複数の接続によって同期応答のルータの負荷への影響を軽減することです。
Hosts do not generally have sufficient information to choose an appropriate randomization interval. This value was selected to ensure randomization of requests over the Quick-Start Interval. In networks where a large number of senders may potentially be impacted by the same signal, a larger value may be desirable (or methods may be used to control this effect in the path change signaling).
ホストは、一般的に、適切なランダム化の間隔を選択するのに十分な情報を持っていません。この値は、クイックスタート間隔でリクエストのランダム化を確実にするために選ばれました。送信者の多くは、潜在的に同一の信号によって影響を受ける可能性があるネットワークでは、大きな値が望ましいかもしれない（または方法は、経路変更シグナリングにおけるこの効果を制御するために使用されてもよいです）。
DCCP implementations are encouraged to support Path MTU Discovery (PMTUD) when applications are able to use a DCCP packet size that exceeds the default Path MTU [RFC4340], [RFC4821]. Quick-Start Requests SHOULD NOT be sent with packets that are used as a PMTUD Probe Packet, since these packets could be lost in the network increasing the probability of loss of the request. It may therefore be preferable to separately negotiate the PMTU and the use of Quick-Start.
アプリケーションは、デフォルトのパスMTU [RFC4340]、[RFC4821]を超えDCCPのパケットサイズを使用することができる場合DCCP実装は、パスMTUディスカバリ（PMTUD）をサポートすることが奨励されます。これらのパケットは、要求の損失の可能性を高めたネットワークで失われる可能性があるので、クイックスタートの要求は、PMTUDプローブパケットとして使用されているパケットを送るべきではありません。したがって、別々PMTUとクイックスタートの使用を交渉することが好ましいです。
The DCCP protocol is datagram-based and therefore the size of the segments that are sent is a function of application behavior as well as being constrained by the largest supported Path MTU.
DCCPプロトコルは、データグラムベースであり、したがって、送信されるセグメントのサイズは、アプリケーションの動作の関数であるだけでなく、最大のサポートされているパスMTUによって制約されます。
A Quick-Start Request is carried in an IPv4 packet option or IPv6 extension header [RFC4782]. Interactions with network devices (middleboxes) that inspect or modify IP options could therefore lead to discard, ICMP error, or DCCP-Reset when attempting to forward packets carrying a Quick-Start Request.
クイックスタート要求をIPv4パケットオプションまたはIPv6拡張ヘッダ[RFC4782]で運ばれます。クイックスタート要求を運ぶパケットを転送しようとしたときに点検やIPオプションを変更するネットワークデバイス（ミドルボックス）との相互作用は、したがって、ICMPエラーを破棄につながる、またはDCCP-リセットできます。
If a DCCP sender sends a DCCP-Request that also carries a Quick-Start Request, and does not receive a DCCP-Response to the packet, the DCCP sender SHOULD resend the DCCP-Request packet without including a Quick-Start Request.
DCCPの送信者はまた、クイックスタート要求を搬送し、パケットのDCCP-応答を受信しないDCCP-Requestを送信すると、DCCPの送信者は、クイックスタート要求を含めずにDCCP-Requestパケットを再送信する必要があります。
Similarly, if a DCCP sender receives a DCCP-Reset in response to a DCCP-Request packet that also carries a Quick-Start Request, then the DCCP sender SHOULD resend the DCCP-Request packet without the Quick-Start Request. The DCCP sender then ceases to use the Quick-Start Mechanism for the remainder of the connection.
DCCP送信者はまた、クイックスタート要求を伝送するDCCP要求パケットに応答して、DCCP-リセットを受信した場合、同様に、次に、DCCP送信者は、クイックスタート要求なしDCCP-Requestパケットを再送すべきです。 DCCPの送信者は、接続の残りのためのクイックスタートメカニズムを使用することを中止します。
A DCCP sender that uses a Quick-Start Request within an established connection and does not receive a response will treat this as non-approval of the request. Successive unsuccessful attempts will result in an exponential increase in the Quick-Start Interval (Section 2.1.1). If this grows to a value exceeding 64 seconds, the DCCP sender ceases to use the Quick-Start Mechanism for the remainder of the connection.
確立された接続内のクイック・スタート・リクエストを使用し、応答を受信しないDCCP送信者は、要求の非承認としてこれを扱います。連続した失敗した試行は、クイックスタート間隔（2.1.1項）の指数関数的な増加になります。これは64秒を超える値に大きくなった場合、DCCPの送信者は、接続の残りのためのクイックスタートメカニズムを使用することを中止します。
The following sections specify the use of Quick-Start with DCCP CCID 2, CCID 3, and for DCCP with TFRC-SP as specified in CCID 4.
以下のセクションでは、DCCP CCID 2、CCID 3とクイックスタートの使用を指定し、TFRC-SPとのDCCPためCCID 4で指定されるように。
This section describes the Quick-Start mechanism to be used with DCCP CCID 2 [RFC4341]. CCID 2 uses a TCP-like congestion control mechanism.
このセクションでは、DCCP CCID 2 [RFC4341]で使用するクイックスタート機構を記載しています。 CCID 2は、TCPのような輻輳制御機構を使用しています。
A Quick-Start Request MAY be sent to allow the sender to determine if it is safe to use a larger initial cwnd. This permits a faster start-up of a new CCID 2 flow.
クイックスタート要求は、より大きな初期のcwndを使用しても安全である場合、送信者が決定できるように送信することができます。これは、新しいCCID 2流れの速い起動を可能にします。
A Quick-Start Request MAY also be sent for an established connection to request a higher sending rate after an idle period or application-limited period (described in Section 2.1). This allows a receiver to use a larger cwnd than allowed with standard operation.
クイックスタート要求は、アイドル期間または（セクション2.1を参照）アプリケーション限られた期間の後に、より高い送信速度を要求する確立された接続のために送られるかもしれません。これは、受信機は、標準的な操作で許可さよりも大きなCWNDを使用することを可能にします。
A Quick-Start Request that follows a reported loss or congestion event MUST NOT request a Quick-Start rate that exceeds the largest congestion window achieved by the CCID 2 connection since the last packet drop (translated to a sending rate).
報告された損失や輻輳イベントを次のクイックスタートリクエストは、（送信レートに換算）最後のパケットドロップ以来、CCID 2接続することによって達成さ最大輻輳ウィンドウを超えるクイックスタート・レートを要求してはなりません。
A receiver processing a Quick-Start Request uses the method described in Section 2.3. On receipt of a Quick-Start Request, the receiver MUST send a Quick-Start Response (even if a receiver is constrained by the ACK Ratio).
クイックスタート要求を処理する受信機は、セクション2.3に記載した方法を使用しています。クイックスタート要求を受信すると、受信機は、クイックスタートレスポンスを（受信機がACK比によって制約されている場合でも）送らなければなりません。
On receipt of a valid Quick-Start Response option, the sender MUST send a Quick-Start Approved option [RFC4782] (see Section 2.3).
有効なクイックスタート応答オプションを受信すると、送信者は、クイックスタート承認オプション[RFC4782]（セクション2.3を参照）を送らなければなりません。
If the approved Quick-Start rate is less than current sending rate, the sender does not enter the Quick-Start Mode, and continues using the procedure defined in CCID 2.
承認されたクイック・スタート・レートは、現在の送信レートよりも小さい場合、送信者は、クイックスタートモードを開始し、CCID 2で定義された手順を使用し続けていません。
If the approved Quick-Start rate at the sender exceeds the current sending rate, the sender enters the Quick-Start Mode and continues in the Quick-Start Mode for a maximum period of one RTT.
送信側で承認されたクイック・スタート・レートは、現在の送信レートを超えた場合、送信者は、クイックスタートモードに入り、1 RTTの最大期間、クイックスタートモードで続行されます。
The sender sets its Quick-Start cwnd (QS_cwnd) as follows:
次のように送信者は、そのクイック・スタートのcwnd（QS_cwnd）を設定します。
QS_cwnd = (R * T) / (s + H) (1)
QS_cwnd =（R *のT）/（S + H）（1）
where R is the Rate Request in bytes per second, T is the measured round-trip path delay (RTT), s is the packet size, and H is the estimated DCCP/IP header size in bytes (e.g., 32 bytes for DCCP layered directly over IPv4, but larger when using IPsec or IPv6).
Rは、秒あたりのバイト数でレート要求であり、Tは測定された往復パス遅延（RTT）ここで、Sはパケットサイズであり、DCCP積層用Hバイト単位で推定DCCP / IPヘッダサイズ（例えば、32のバイト直接のIPv4上が、IPSecまたはIPv6を使用する場合）より大きい。
A CCID 2 sender MAY then increase its cwnd to the QS_cwnd. The cwnd should not be reduced (i.e., a QS_cwnd lower than cwnd should be ignored, since the CCID 2 congestion control method already permits this rate). CCID 2 is not a rate-paced protocol. Therefore, if the QS_cwnd is used, the sending host MUST implement a suitable method to pace the rate at which the Quick-Start Packets are sent until it receives a DCCP-ACK for a packet sent during the Quick-Start Mode [RFC4782]. The sending host SHOULD also record the previous cwnd and note that the new cwnd has been determined by Quick-Start, rather by other means (e.g., by setting a flag to indicate that it is in Quick-Start Mode).
CCID 2送信者は、その後QS_cwndにそのにcwndを増加させることができます。 CWNDは、（CCID 2輻輳制御方法は、既にこのレートを可能にするため、すなわち、CWNDより低いQS_cwndは、無視されなければならない）減少されるべきではありません。 CCID 2は、レートペースプロトコルではありません。 QS_cwndが使用される場合、したがって、送信ホストは、クイックスタートモード[RFC4782]の間に送信されたパケットのためにDCCP-ACKを受信するまでクイックスタートパケットが送信される速度をペーシングするために適切な方法を実装しなければなりません。送信ホストは、以前のCWNDを記録し、新しいCWNDは、（それがクイックスタートモードであることを示すフラグを設定することにより、例えば）、むしろ他の手段によって、クイックスタートによって決定されていることに注意してください。
When the sender receives the first DCCP-ACK to a packet sent in the Quick-Start Mode, it leaves the Quick-Start Mode and enters the Validation Phase.
送信者がクイックスタートモードで送信されたパケットに最初DCCP-ACKを受信すると、クイックスタートモードを出て、検証フェーズに入ります。
A CCID 2 sender MAY continue to send at the paced Quick-Start Rate while in the Validation Phase. It leaves the Validation Phase on receipt of an ACK that acknowledges the last Quick-Start Packet, or if the validation phase persists for a period that exceeds the Quick-Start Validation Time of 1 RTT. It MUST then reduce the cwnd to the actual flight size (the current amount of unacknowledged data sent) [RFC4782] and uses the congestion control methods specified for CCID 2.
CCID 2送信者は、検証フェーズにおけるながらペースクイックスタートレートで送信し続けることがあります。それは最後のクイックスタートパケットを承認ACKの受信時に検証フェーズを残し、または検証フェーズは1 RTTのクイックスタートの検証時間を超える期間の間持続する場合。次に、実際の飛行のサイズ（送信された未確認データの現在の量）[RFC4782]にCWNDを減少させ、CCID 2に指定された輻輳制御方法を使用しなければなりません。
A sender in the Quick-Start Mode (or Validation Phase) that detects congestion (e.g., receives a feedback packet that reports new packet loss or a packet with a congestion marking), MUST immediately leave the Quick-Start Mode (or Validation Phase). It then resets the cwnd to half the recorded previous cwnd and enters the congestion avoidance phase described in [RFC4341].
輻輳を検出し、クイックスタートモード（または検証フェーズ）での送信者は、すぐに、クイックスタートモード（または検証フェーズ）を残しておく必要があります（例えば、新しいパケットロスや輻輳がマーキングされたパケットを報告し、フィードバックパケットを受信します） 。その後、半記録前にCWND CWNDをリセットし、[RFC4341]に記載の輻輳回避フェーズに入ります。
In the absence of any feedback at the end of the Validation period, the sender resets the cwnd to half the recorded previous cwnd and enters the congestion avoidance phase.
検証期間の終了時のいずれかのフィードバックが存在しない場合には、送信者が半分記録前にCWND CWNDをリセットし、輻輳回避フェーズに入ります。
A CCID 2 receiver sends feedback for groups of received packets [RFC4341]. Approval of a higher transmission rate using Quick-Start will increase control traffic on the reverse path. A return path that becomes congested could have a transient negative impact on other traffic flows sharing the return link. The lower rate of feedback will then limit the achievable rate in the forward direction.
CCID 2受信機は、受信されたパケット[RFC4341]のグループのためのフィードバックを送信します。クイックスタートを使用して、より高い伝送速度の承認は逆の経路上の制御トラフィックが増加します。他のトラフィックへの過渡的影響を与える可能性が輻輳したリターンパスは、リターンリンクを共有して流れています。フィードバックの低いレートは、その後、順方向に実現可能なレートを制限します。
This section describes the Quick-Start mechanism to be used with DCCP CCID 3 [RFC4342]. The rate-based congestion control mechanism used by CCID 3 leads to specific issues that are addressed by Quick-Start in this section.
このセクションでは、DCCP CCID 3 [RFC4342]で使用するクイックスタート機構を記載しています。 CCID 3で使用されるレートベースの輻輳制御機構は、このセクションでクイックスタートによって対処されている特定の問題につながります。
A Quick-Start Request MAY be sent to allow the sender to determine if it is safe to use a larger initial sending rate. This permits a faster start-up of a new CCID 3 flow.
クイックスタート要求は、大きな初期送信レートを使用しても安全である場合、送信者が決定できるように送信することができます。これは、新しいCCID 3流れの速い起動を可能にします。
A Quick-Start Request MAY also be sent to request a higher sending rate after an idle period (in which the nofeedback timer expires [RFC5348]) or an application-limited period (described in Section 2.1). This allows a receiver to increase the sending rate faster than allowed with standard operation (i.e., faster than twice the rate reported by a CCID 3 receiver in the most recent feedback message).
クイックスタート要求は、アイドル期間（NOFEEDBACKタイマーが満了した[RFC5348]）または（セクション2.1を参照）アプリケーション限られた期間の後に、より高い送信率を要求に送信することができます。これは、受信機は、標準的な操作で許可さよりも送信速度より速く増加することを可能にする（即ち、最も最近のフィードバックメッセージにおいてCCID 3受信機によって報告速く2倍率）。
The requested rate specified in a Quick-Start Request MUST NOT exceed the TFRC-controlled sending rate [RFC4342] when this is bounded by the current loss event rate (if any), either from calculation at the sender or from feedback received from the receiver. CCID 3 considers this rate is a safe response in the presence of expected congestion.
これは、送信者の計算から、または受信機から受信したフィードバックのいずれかから、現在の損失イベント率（もしあれば）によって制限される場合クイックスタート要求で指定された要求されたレートは、TFRC制御送信レート[RFC4342]を超えてはなりません。 CCID 3は、この率は期待混雑の存在下で安全な反応であると考えています。
When processing a received Quick-Start Request, the receiver uses the method described in Section 2.3. In addition, if a CCID 3 receiver uses the window counter to send periodic feedback messages, then the receiver sets its local variable last_counter to the value of the window counter reported by the segment containing the Quick-Start Request. The next feedback message would then be sent when the window_counter is greater or equal to last_counter + 4. If the CCID 3 receiver uses a feedback timer to send period feedback messages, then the receiver MUST reset the CCID 3 feedback timer, causing the feedback to be sent as soon as possible. This helps to align the timing of feedback to the start and end of the period in which Quick-Start Packets are sent, and will normally result in feedback at a time that is approximately the end of the period when Quick-Start Packets are received.
受信されたクイックスタート要求を処理するとき、受信機は、セクション2.3に記載した方法を使用しています。 CCID 3受信機は、周期的なフィードバックメッセージを送信するためにウィンドウカウンタを使用する場合に加えて、受信機はクイックスタート要求を含むセグメントによって報告されたウィンドウのカウンタの値にそのローカル変数last_counterを設定します。 window_counterはCCID 3受信機は、受信機は、CCID 3フィードバックタイマをリセットするためにフィードバックを引き起こすしなければならない期間のフィードバックメッセージを送信するためのフィードバック・タイマを使用している場合は+ 4をlast_counter以上である場合、次のフィードバック・メッセージが送信されますできるだけ早く送ること。これは、クイックスタートパケットが送信される期間の開始と終了へのフィードバックのタイミングを合わせるのに役立ち、そして通常は約クイックスタートパケットを受信している期間の終了である時に、フィードバックになります。
On receipt of a valid Quick-Start Response option, the sender MUST send a Quick-Start Approved option [RFC4782] (see Section 2.3). The sender then uses one of three procedures:
有効なクイックスタート応答オプションを受信すると、送信者は、クイックスタート承認オプション[RFC4782]（セクション2.3を参照）を送らなければなりません。送信者は、次の3つのいずれかの手順を使用します。
* If the approved Quick-Start rate is less than the current sending rate, the sender does not enter the Quick-Start Mode and continues using the procedure defined in CCID 3.
*承認されたクイック・スタート・レートは、現在の送信レートよりも小さい場合には、送信者がクイックスタートモードに入り、CCID 3で定義された手順を使用し続けていません。
* If loss or congestion is reported after sending the Quick-Start Request, the sender also does not enter the Quick-Start Mode and continues using the procedure defined in CCID 3.
*損失や輻輳がクイックスタートリクエストを送信した後に報告された場合、送信者はまた、クイックスタートモードに入り、CCID 3で定義された手順を使用し続けていません。
* If the approved Quick-Start rate exceeds the current sending rate, the sender enters the Quick-Start Mode and continues in the Quick-Start Mode for a maximum period of 1 RTT. The sender sets its Quick-Start sending rate (QS_sendrate) as follows:
承認されたクイック・スタート・レートは、現在の送信レートを超えた場合*、送信者は、クイックスタートモードに入り、1 RTTの最大期間、クイックスタートモードで続行されます。次のように送信者は、そのクイックスタート送信レート（QS_sendrate）を設定します。
QS_sendrate = R * s/(s + H); (2)
QS_sendrate = R * S /（S + H）。 （2）
where R the Rate Request in bytes per second, s is the packet size [RFC4342], and H the estimated DCCP/IP header size in bytes (e.g., 32 bytes for IPv4). A CCID 3 host MAY then increase its sending rate to the QS_sendrate. The rate should not be reduced.
ここでは、秒あたりのバイト数にレート要求をR、S、パケットサイズ[RFC4342]であり、そしてHバイト単位で推定DCCP / IPヘッダサイズ（例えば、IPv4の場合32バイト）。 CCID 3ホストは、QS_sendrateへの送信速度を増加させることができます。率は減少してはなりません。
CCID 3 is a rate-paced protocol. Therefore, if the QS_sendrate is used, the sending host MUST pace the rate at which the Quick-Start Packets are sent over the next RTT. The sending host SHOULD also record the previous congestion-controlled rate and note that the new rate has been determined by Quick-Start rather by other means (e.g., by setting a flag to indicate that it is in the Quick-Start Mode).
CCID 3はレートペースプロトコルです。 QS_sendrateが使用されている場合はそのため、送信側ホストは、クイックスタートパケットは次のRTTを介して送信される速度をペースしなければなりません。送信ホストは、以前の輻輳制御された速度を記録し、新しい速度が（それがクイックスタートモードであることを示すフラグを設定することにより、例えば）他の手段ではなくクイックスタートによって決定されていることに注意してください。
The sender exits the Quick-Start Mode after either:
送信者は、どちらかの後にクイックスタートモードを終了します。
* Receipt of a feedback packet acknowledging one or more Quick-Start Packets,
*一つ以上のクイックスタートパケットを認めるフィードバックパケットの領収書、
* A period of 1 RTT after receipt of a Quick-Start Response, or
*クイックスタートレスポンスを受信した後、1 RTTの期間、または
* Detection of a loss or congestion event (see Section 3.2.5).
*紛失や輻輳イベントの検出（3.2.5項を参照してください）。
After transmitting a set of Quick-Start Packets in the Quick Start Mode (and providing that no loss or congestion marking is reported), the sender enters the Quick-Start Validation Phase. A sender that receives feedback that reports a loss or congestion event MUST follow the procedures described in Section 3.2.5.
クイックスタートモードでのクイックスタートパケットのセットを送信（及び損失又は輻輳のマーキングが報告されていないことを提供する）後、送信者は、クイックスタート検証フェーズに入ります。損失や輻輳イベントは3.2.5項で説明した手順に従わなければならない報告のフィードバックを受けて、送信者。
The sender MUST exit the Quick-Start Validation Phase on receipt of feedback that acknowledges all packets sent in the Quick-Start Mode (i.e., all Quick-Start Packets) or if the Validation Phase persists for a period that exceeds the Quick-Start Validation Time of two RTTs.
送信者は、クイックスタートモードで送信されるすべてのパケットを認識し、フィードバックを受けてクイックスタートの検証フェーズ（すなわち、すべてのクイックスタートパケット）を終了する必要がありますか検証フェーズは、クイックスタートの検証を超えた期間持続する場合2つのRTTの時間。
A sender that completes the Quick-Start Validation Phase with no reported packet loss or congestion stops using the QS_sendrate and MUST recalculate a suitable sending rate using the standard congestion control mechanisms [RFC4342].
無報告パケット損失または混雑してクイックスタート検証フェーズを完了し、送信者はQS_sendrateの使用を停止し、標準的な輻輳制御メカニズム[RFC4342]を使用して、適切な送信レートを再計算しなければなりません。
If no feedback is received within the Quick-Start Validation Phase, the sender MUST return to the minimum of the recorded original rate (at the start of the Quick-Start Mode) and one half of the QS_sendrate. The nofeedback timer is also reset.
何のフィードバックがクイックスタートの検証フェーズ中に受信されない場合、送信者はとQS_sendrateの半分（クイック・スタート・モードの開始時に）記録された元のレートの最小値に戻る必要があります。 NOFEEDBACKタイマーもリセットされます。
3.2.5. Reported Loss or Congestion during the Quick-Start Mode or Validation Phase
3.2.5. クイックスタートモードまたは検証フェーズ中に報告損失または輻輳
A sender in the Quick-Start Mode or Validation Phase that detects congestion (e.g., receives a feedback packet that reports new packet loss or a packet with a congestion marking) MUST immediately leave the Quick-Start Mode or Validation Phase and enter the congestion avoidance phase [RFC4342]. This implies re-calculating the sending rate, X, as required by RFC 4342:
輻輳を検出し、クイックスタートモードまたは検証フェーズでは、送信者は、直ちに、クイックスタートモードまたは検証フェーズを残し、輻輳回避を入力する必要があります（例えば、新しいパケット損失またはマーキング渋滞でパケットを報告し、フィードバックパケットを受信します）相[RFC4342]。これは、送信速度を再計算意味し、X、RFC 4342によって要求されます。
X = max(min(X_calc, 2*X_recv), s/t_mbi);
X = MAX（分（X_calc、2 * X_recv）、S / t_mbi）。
where X_calc is the transmit rate calculated by the throughput equation, X_recv is the reported receiver rate, s is the packet size and t_mbi is the maximum back-off interval of 64 seconds.
X_calcスループット方程式によって算出伝送速度であり、X_recv報告受信速度であり、Sは、パケットサイズとt_mbi 64秒の最大バックオフ間隔です。
The current specification of TFRC [RFC5348], which obsoletes RFC 3448, uses a set of X_recv values and uses the maximum of the set during application-limited intervals. This calculates the sending rate, X as:
RFC 3448時代遅れTFRC [RFC5348]の現在の仕様は、X_recv値のセットを使用し、アプリケーションが制限された時間間隔の間セットの最大値を使用します。これは、送信速度、Xなどを計算します。
X = max(min(X_calc, recv_limit),s/t_mbi);
X = MAX（分（X_calc、recv_limit）、S / t_mbi）。
where recv_limit could be max(X_recv_set) or 2*max(X_recv_set) depending on whether there was a new loss event during a data-limited interval, or no loss event during an application-limited interval respectively. When the sender is not application-limited, the recv_limit is set to 2*max(X_recv_set).
データ制限期間中に新しい損失イベント、またはそれぞれのアプリケーションが制限された間隔の間無損失イベントがあったかどうかに応じてrecv_limitを最大とすることができる（X_recv_set）または2 * MAX（X_recv_set）。送信者はアプリケーションが制限されていない場合は、recv_limitは、2 *最大（X_recv_set）に設定されています。
A sender using RFC 4342 updated by [RFC5348], calculates the sending rate, X, using the above formula normatively defined in [RFC5348].
[RFC5348]によって更新RFC 4342を使用して送信者は、規範[RFC5348]で定義された上記の式を用いて、送信レート、Xを算出します。
A CCID 3 receiver sends feedback at least once each RTT [RFC4342]. Use of Quick-Start is therefore not expected to significantly increase control traffic on the reverse path.
CCID 3受信機は、少なくとも一度は各RTT [RFC4342]フィードバックを送信します。クイックスタートの使用は、したがって、大幅にリバースパス上の制御トラフィックを増加すると予想されていません。
This section describes the Quick-Start mechanism to be used when DCCP uses TFRC-SP [RFC4828] in place of TFRC [RFC5348], as specified in CCID 4 [RFC5622]. CCID 4 is similar to CCID 3 except that a sender using CCID 4 is limited to a maximum of 100 packets/second.
このセクションでは、DCCPは、TFRC [RFC5348]の代わりに、TFRC-SP [RFC4828]を使用する場合、CCID 4 [RFC5622]で指定されるように、使用されるクイックスタート機構が記載されています。 CCID 4は、CCID 4を使用して送信者が100個のパケット/秒の最大値に制限されていることを除いてCCID 3と同様です。
The Quick-Start procedure defined below therefore resembles that for CCID 3.
したがって、以下に定義クイックスタート手順は、CCID 3のためということに似ています。
The procedure for sending a Quick-Start Request using CCID 4 is the same as for CCID 3, defined in Section 3.2.1. In addition, the requested rate MUST be less than or equal to the equivalent of a sending rate of 100 packets per second [RFC4828]. CCID 4 [RFC4828] specifies that the allowed sending rate derived from the TCP throughput equation is reduced by a factor that accounts for packet header size.
CCID 4を用いたクイックスタート要求を送信するための手順は、セクション3.2.1で定義され、CCID 3の場合と同じです。また、要求されたレートは、以下毎秒100個のパケット[RFC4828]の送信速度と同等に等しくなければなりません。 CCID 4 [RFC4828]はTCPスループット方程式に由来許容送信率は、パケットヘッダのサイズを考慮に低減されることを指定します。
This procedure is the same as for CCID 3, defined in Section 3.2.2.
この手順は、3.2.2項で定義され、CCID 3の場合と同じです。
This procedure is the same as for CCID 3, defined in Sections 3.2.3, 3.2.4, and 3.2.5, except that the congestion control procedures is updated to use TFRC-SP [RFC4828].
この手順は、輻輳制御手順はTFRC-SP [RFC4828]を使用するように更新されることを除いて、セクション3.2.3、3.2.4で定義され、CCID 3と同じであり、3.2.5。
A CCID 4 sender does not need to account for headers a second time when translating the approved Quick-Start rate into an allowed sending rate (as described in Section 5 of [RFC5622].
[RFC5622]のセクション5に記載されているように（許容送信レートに承認されたクイック・スタート・レートを変換するときCCID 4送信者がヘッダの第二の時間を考慮する必要はありません。
This procedure is the same as for CCID 3, defined in Section 3.2.5, except that the congestion control procedures is updated to use TFRC-SP [RFC4828].
この手順は、輻輳制御手順はTFRC-SP [RFC4828]を使用するように更新されることを除いて、セクション3.2.5で定義され、CCID 3の場合と同じです。
A CCID 4 receiver sends feedback at least once each RTT. Use of Quick-Start is therefore not expected to significantly increase control traffic on the reverse path.
CCID 4受信機は、少なくとも一度は各RTTフィードバックを送信します。クイックスタートの使用は、したがって、大幅にリバースパス上の制御トラフィックを増加すると予想されていません。
The considerations for using Quick-Start with DCCP are not significantly different to those for Quick-Start with TCP. The document does not modify the router behavior specified for Quick-Start.
DCCPとクイックスタートを使用するための考慮事項は、TCPとクイックスタートのためのものと大きく異なるものではありません。文書には、クイックスタートのために指定されたルータの動作を変更しません。
The less frequent feedback of DCCP raises an issue in that a sender using Quick-Start may continue to use the rate specified by a Quick-Start Response for a period that exceeds one path round trip time (i.e., that which TCP would have used). This overrun is a result of the less frequent feedback interval used by DCCP (i.e., CCID 2 may delay feedback by at most one half cwnd and CCID 3 and CCID 4 provide feedback at least once per RTT). In the method specified by this document, the Quick-Start Validation Phase bounds this overrun to be not more than an additional two RTTs.
DCCPのあまり頻繁にフィードバックはクイックスタートを使用して送信者が一つのパスのラウンドトリップ時間（すなわち、TCPを使用していたもの）を超える期間、クイックスタートレスポンスで指定されたレートを使用し続けることができるで問題を提起します。このオーバーランがDCCPによって使用されるより少ない頻度のフィードバック間隔の結果である（すなわち、CCID 2は最大で半分のCWNDによってフィードバックを遅らせ、CCID 3及びCCID 4はRTTごとに少なくとも一度のフィードバックを提供することができます）。この文書で指定された方法で、クイックスタートの検証フェーズの境界では、このオーバーランは、追加の2つのRTTよりもないことにします。
The selected method was chosen as a compromise that reflects the need to terminate quickly following the loss of a feedback packet, and the need to allow sufficient time for end host and router processing, as well as the different perceptions of the path RTT held at the sender and receiver. Any reported loss or congestion results in immediate action without waiting for completion of the Quick-Start Validation period.
選択された方法は、フィードバックパケットの損失以下迅速に終了する必要があり、エンドホストとルータの処理のために十分な時間を許可する必要があり、同様にRTTがで開催された経路の異なる認識を反映して妥協点として選択されました送信者と受信者。任意のクイックスタートの検証期間の終了を待たずに直ちに行動の損失や輻輳の結果を報告しました。
There are many cases in which Quick-Start Requests would not be approved [RFC4782]. These include communication over paths containing routers, IP tunnels, MPLS paths, and the like, that do not support Quick-Start. These cases also include paths with routers or middleboxes that drop packets containing IP options (or IPv6 extensions). Quick-Start Requests could be difficult to approve over paths that include multi-access Layer-2 networks.
クイックスタート要求は[RFC4782]を承認されない場合が多いです。これらは、クイックスタートをサポートしていないルータを含む経路を介した通信、IPトンネル、MPLSパスなどを含みます。これらの場合は、IPオプション（またはIPv6拡張）を含むパケットをドロップルータ又は中間装置との経路を含みます。クイックスタートの要求は、マルチアクセスレイヤ2ネットワークを含む経路を介して承認することは困難である可能性があります。
Transient effects could arise when the transport protocol packets associated with a connection are multiplexed over multiple parallel (sometimes known as alternative) links or network-layer paths, and Quick-Start is used, since it will be effective on only one of the paths, but could lead to increased traffic on all paths.
接続に関連付けられているトランスポート・プロトコル・パケットはリンクまたはネットワーク層経路（時々代替として知られている）複数の並列上に多重化され、クイックスタートが使用される場合、それはパスの一方のみに有効となりますので、過渡効果は、発生する可能性しかし、すべてのパス上のトラフィックの増加につながる可能性があります。
A CCID 2 sender using Quick-Start can increase the control traffic on the reverse path, which could have a transient negative impact on other traffic flows sharing the return link (Section 3.1.6). The lower rate of feedback will then limit the achievable rate in the forward direction.
クイックスタートを使用してCCID 2送信者は、他のトラフィックに過渡的負の影響はリターンリンク（3.1.6）を共有流れかもしれない逆の経路上で制御トラフィックを増やすことができます。フィードバックの低いレートは、その後、順方向に実現可能なレートを制限します。
[RFC4782] also describes environments where the Quick-Start mechanism could fail with false positives, with the sender incorrectly assuming that the Quick-Start Request had been approved by all of the routers along the path. As a result of these concerns, and as a result of the difficulties and the seeming absence of motivation for routers, such as core routers, to deploy Quick-Start, Quick-Start has been proposed as a mechanism that could be of use in controlled environments, and not as a mechanism that would be intended or appropriate for ubiquitous deployment in the global Internet.
[RFC4782]もクイックスタートメカニズムは、送信者が誤ってクイックスタートリクエストはパスに沿ったルーターのすべてによって承認されていたと仮定して、偽陽性と失敗する可能性があり環境について説明します。これらの懸念の結果として、及び問題とそのようなコアルータとしてルータ、動機の見せかけの欠如の結果として、クイックスタートを展開するには、クイックスタートが制御に有用であり得るメカニズムとして提案されています環境、およびないグローバルなインターネットにおけるユビキタス展開するためのものか、適切であろうメカニズムとして。
Further experimentation would be required to confirm the deployment of Quick-Start and to investigate performance issues that may arise, prior to any recommendation for use over the general Internet.
さらなる実験は、クイックスタートの展開を確認し、前の一般的なインターネット上での使用のための任意の勧告に、発生する可能性のあるパフォーマンスの問題を調査するために必要とされるであろう。
IANA has assigned a DCCP Option Type (45) from the DCCP Option Types Registry. This Option is applicable to all CCIDs and is known as the "Quick-Start Response" Option and is defined in Section 2.2.1. It specifies a length value in the format used for options numbered 32-128.
IANAは、DCCPオプションタイプレジストリからDCCPオプションタイプ（45）を割り当てました。このオプションは、すべてのCCIDsに適用可能であり、「クイックスタートレスポンス」のオプションとして知られており、セクション2.2.1で定義されています。これは、32から128番のオプションのために使用される形式での長さの値を指定します。
The author gratefully acknowledges the previous work by Sally Floyd to identify issues that impact Quick-Start for DCCP, and her comments to improve this document. We also acknowledge comments and corrections from Pasi Sarolahti, Vincent Roca, Mark Allman, Michael Scharf, and others in the IETF DCCP Working Group (WG).
作者は感謝し、この文書を改善するために、DCCPのためのクイックスタートに影響を与える問題、そして彼女のコメントを識別するためのサリー・フロイド前作を認めています。我々はまた、IETF DCCPワーキンググループ（WG）のコメントとパシSarolahti、ヴィンセントロカ、マーク・オールマン、マイケル・シャーフからの修正などを認めます。
Security issues are discussed in [RFC4782]. Middlebox deployment issues are also highlighted in Section 2.8. No new security issues are raised within this document.
セキュリティの問題は、[RFC4782]で議論されています。ミドル展開に関する問題も、2.8節で強調表示されています。新たなセキュリティ問題はこの文書内提起されていません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[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月。
[RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control", RFC 4341, March 2006.
[RFC4341]フロイド、S.、およびE.コーラー、 "データグラム輻輳制御プロトコル（DCCP）輻輳制御ID 2用のプロフィール：TCPのような輻輳制御"、RFC 4341、2006年3月。
[RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, March 2006.
[RFC4342]フロイド、S.、コーラー、E.、およびJ. Padhye、 "データグラム混雑制御プロトコル（DCCP）輻輳制御ID 3のプロフィール：TCPフレンドリーレート制御（TFRC）"、RFC 4342、2006年3月。
[RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick-Start for TCP and IP", RFC 4782, January 2007.
[RFC4782]フロイド、S.、オールマン、M.、ジャイナ教、A.、およびP. Sarolahti、 "TCPとIPのためのクイックスタート"、RFC 4782、2007年1月。
[RFC4828] Floyd, S. and E. Kohler, "TCP Friendly Rate Control (TFRC): The Small-Packet (SP) Variant", RFC 4828, April 2007.
[RFC4828]フロイド、S.、およびE.コーラー、 "TCPフレンドリーレート制御（TFRC）：小パケット（SP）バリアント"、RFC 4828、2007年4月。
[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 5348, September 2008.
[RFC5348]フロイド、S.、ハンドリー、M.、Padhye、J.、およびJ.ウィトマー、 "TCPフレンドリーレート制御（TFRC）：プロトコル仕様"、RFC 5348、2008年9月。
[RFC5622] Floyd, S., and E. Kohler, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate Control for Small Packets (TFRC-SP)", RFC 5622, August 2009.
[RFC5622]フロイド、S.、およびE.コーラー、 "データグラム輻輳制御プロトコル（DCCP）輻輳ID 4のためのプロフィール：小パケット用のTCPフレンドリーレート制御（TFRC-SP）"、RFC 5622、2009年8月。
[RFC3344] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[RFC3344]パーキンス、C.、エド。、 "IPv4のIPモビリティサポート"、RFC 3344、2002年8月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775]ジョンソン、D.、パーキンス、C.、およびJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 3775、2004年6月。
[RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's Initial Window", RFC 3390, October 2002.
[RFC3390]オールマン、M.、フロイド、S.、およびC.ヤマウズラ、 "増加するTCPの初期ウィンドウ"、RFC 3390、2002年10月。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007.
[RFC4821]マシス、M.とJ. Heffner、 "パケット化レイヤのパスMTUディスカバリ"、RFC 4821、2007年3月。
Authors' Addresses
著者のアドレス
Godred Fairhurst School of Engineering University of Aberdeen Aberdeen, AB24 3UE Scotland, UK
アバディーン、AB24 3UEスコットランド、英国のエンジニアリング大学のGodred Fairhurst学校
EMail: gorry@erg.abdn.ac.uk URI: http://www.erg.abdn.ac.uk/users/gorry
電子メール：gorry@erg.abdn.ac.uk URI：http://www.erg.abdn.ac.uk/users/gorry
Arjuna Sathiaseelan School of Engineering University of Aberdeen Aberdeen, AB24 3UE Scotland, UK
アバディーン、AB24 3UEスコットランド、英国のエンジニアリング大学のアルジュナSathiaseelan学校
EMail: arjuna@erg.abdn.ac.uk URI: http://www.erg.abdn.ac.uk/users/arjuna
電子メール：arjuna@erg.abdn.ac.uk URI：http://www.erg.abdn.ac.uk/users/arjuna