[要約] RFC 5634は、DCCPのクイックスタートに関するガイドラインです。その目的は、DCCPの効果的な利用とネットワークの過負荷を回避するための手法を提供することです。
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)
データグラムの混雑制御プロトコルのクイックスタート（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 CCIDに適用される一般的な手順と、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.
このメモは、インターネットコミュニティ向けの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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.
Datagram混雑制御プロトコル（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]で指定されています。セクション2で説明されているすべてのDCCP CCIDに適用される一般的な手順があり、セクション3で説明されている個々のCCIDがどのように動作するかに関連する詳細があります。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.
Quick-Start [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 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.
このドキュメントでは、読者がRFC 4782 [RFC4782]に精通していると想定しています。これは、IPおよびTCPでクイックスタートの使用を指定しています。RFC 4782のセクション7では、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ヘッダーでクイックスタートオプションを使用して、1秒あたりのバイトでの目的の送信レートを示します。パスに沿ったクイックスタート対応の各ルーターは、要求されたレートを承認するか、要求された料金を下げるか、クイックスタート要求が承認されていないことを示します。
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）に1回）。そのような場合、クイックスタートを使用する送信者は、異なるメカニズムを実装して、クイックスタートの送信率がネットワークによって維持されているかどうかを判断する必要があります。これにより、クイックスタート検証フェーズ（セクション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).
さらに、このドキュメントでは、フローが開始された後にクイックスタートの使用を改良する2つのさらに一般的な機能強化を定義します（DCCPを使用したアプリケーションではより一般的になると予想されます）。これらは、クイックスタート間隔（セクション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]).
DCCP送信者は、接続の開始時にクイックスタートリクエストを使用する場合があります。送信者は、標準メカニズム（[RFC5348]または[RFC3390]など）で許可されるよりも大きな初期レートを好む場合があります。
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-DATAなどの確認が必要なパケットを使用してクイックスタートリクエストを送信する必要があります。
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).
クイックスタートメカニズムの過度の使用は望ましくありません。このドキュメントでは、RFC 4782の強化を定義して、DCCPフローが開始された後のクイックスタートの使用を更新して、クイックスタート間隔の概念を導入します。クイックスタート間隔は、クイックスタートリクエストを送信しない期間を指定します。クイックスタート間隔は、以前のクイックスタートリクエストの送信時から測定されます（セクション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.
接続が確立されると、クイックスタートインターバルが初期_QSIに初期化されます。initial_qsiは少なくとも6秒でなければなりません（より大きな値が許可されています）。この値は、典型的なインターネットパスでの過度のルーター処理を防ぐのに十分な大きさになるように選択されました。流入あたりの状態を追跡するクイックスタートルーターは、6秒未満の間隔で同じフローのクイックスタート要求を行うフローのクイックスタート処理を一時停止することにより、送信者にペナルティを科すことができます。
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);
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).
したがって、それぞれのクイックスタートリクエストに失敗すると、クイックスタート間隔が2倍になります（結果として指数関数的なバックオフになります）。送信者が戻すことができる最大時間は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パケットを受信するエンドホストは、クイックスタートリクエストに合格し、IP Time to Live（TTL）フィールドの値が受信DCCPレイヤーに渡されます。受信ホストがクイックスタートリクエストを許可することをいとわない場合、対応するフィードバックパケットのDCCPヘッダーにクイックスタート応答オプションを搭載するパケットを送信することにより、すぐに応答する必要があります（例：DCCP-CACKパケットを使用するか、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).
クイックスタート応答オプションのレートリクエストフィールドは、Quick-Startオプションでのレートリクエストの受信値、またはDCCPレシーバーがより低いレートリクエストのみを許可する場合の低い値に設定されます。情報が利用可能な場合（たとえば、ローカルレイヤー2インターフェイス速度の知識）、クイックスタートレシーバーは、受信レートが予想される受信リンク容量を超えないことを確認する必要があります。クイックスタート応答のTTL差分フィールドは、受信したIP TTL値（IPv6のホップ制限フィールド）とクイックスタートTTL値の差に設定されます。応答のクイックスタートNonCEは、クイックスタートオプション（またはIPv6ヘッダー拡張機能）のクイックスタートNONCEの受信値に設定されます。
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.
ネットワークで失われた場合、クイックスタート応答はresしてはなりません[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番目のバイトには、4ビット予約フィールドと、IPクイックスタートレートリクエストオプション[RFC4782]のようにフォーマットされた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 DIFFが含まれています。TTL DIFFには、[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ビットのクイックスタートNonCEと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コントロールパケットを使用してオプションとして送信されます。
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つのRTT（1つ以上のクイックスタートパケットの受信を認めてフィードバックメッセージが到着すると、より短い期間続きます）。
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各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）よりも少ない期間内にクイックスタートリクエストを送信してはなりません。つまり、新しいクイックスタートリクエストを送信する前に、以前のリクエストの後に少なくとも初期_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.
- 以前の初期_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.
DCCPの実装は、アプリケーションがデフォルトのPATH MTU [RFC4340]、[RFC4821]を超えるDCCPパケットサイズを使用できる場合、PATH MTU Discovery（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-Resetにつながる可能性があります。
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-Requestパケットに応じて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を使用したクイックスタートの使用、およびCCID 4で指定されているTFRC-SPを使用したDCCPの使用を指定します。
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)
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は1秒あたりのバイトのレート要求です。Tは測定された往復パス遅延（RTT）、Sはパケットサイズ、Hは推定DCCP/IPヘッダーサイズでバイト（例えば、DCCP層の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の送信者は、そのCWNDをQS_CWNDに増やす可能性があります。CWNDを減らすべきではありません（つまり、CCID 2の混雑制御方法はすでにこのレートを許可しているため、CWNDよりも低いQS_CWNDを無視する必要があります）。CCID 2はレートペースのプロトコルではありません。したがって、QS_CWNDを使用する場合、送信ホストは、クイックスタートモード[RFC4782]中に送信されたパケットのDCCP-CACKを受信するまで、クイックスタートパケットが送信されるレートをペースするために適切な方法を実装する必要があります。また、送信ホストは以前の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-CACKを受信すると、クイックスタートモードを離れ、検証フェーズに入ります。
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のクイックスタート検証時間を超える期間、検証フェーズが持続する場合。次に、CWNDを実際のフライトサイズ（送信された未充填データの現在の量）[RFC4782]に減らし、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がlast_counter 4に大きいか等しい場合に送信されます。CCID3レシーバーがフィードバックタイマーを使用してピリオドフィードバックメッセージを送信する場合、レシーバーはCCID 3フィードバックタイマーをリセットし、フィードバックを引き起こす必要があります。できるだけ早く送信されます。これにより、フィードバックのタイミングをクイックスタートパケットが送信される期間の開始時と終了に合わせるのに役立ち、通常、クイックスタートパケットが受信された期間のほぼ終了時にフィードバックが発生します。
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)
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レート要求は1秒あたりのバイトで、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,
* 1つ以上のクイックスタートパケットを認めるフィードバックパケットの受信、
* 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タイマーもリセットされています。
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]。これは、RFC 4342で要求されるように、送信率Xを再計算することを意味します。
X = max(min(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 = max(min(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*max（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]を少なくとも1回フィードバックを送信します。したがって、クイックスタートの使用は、リバースパスでの制御トラフィックを大幅に増加させるとは期待されていません。
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.
このセクションでは、CCID 4 [RFC5622]で指定されているように、DCCPがTFRC [RFC5348]の代わりにTFRC-SP [RFC4828]を使用する場合に使用されるクイックスタートメカニズムについて説明します。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と同じです。さらに、要求されたレートは、1秒あたり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].
この手順は、セクション3.2.3、3.2.4、および3.2.5で定義されているCCID 3の場合と同じです。ただし、TFRC-SP [RFC4828]を使用するために混雑制御手順が更新されます。
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].
CCID 4送信者は、承認されたクイックスタートレートを許可された送信率に変換するときに、ヘッダーを2回目に考慮する必要はありません（[RFC5622]のセクション5で説明されています。
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を少なくとも1回フィードバックを送信します。したがって、クイックスタートの使用は、リバースパスでの制御トラフィックを大幅に増加させるとは期待されていません。
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の頻度の低いフィードバックは、クイックスタートを使用している送信者が、1つのパスラウンドトリップ時間（つまり、TCPが使用したもの）を超える期間のクイックスタート応答で指定されたレートを引き続き使用できる可能性があるという点で問題を提起します。。このオーバーランは、DCCPが使用する頻度の低いフィードバック間隔の結果です（つまり、CCID 2は、最大半分のCWNDとCCID 3およびCCID 4により、RTTごとに少なくとも1回フィードバックを提供する可能性があります）。このドキュメントで指定されたメソッドでは、クイックスタート検証フェーズは、このオーバーランを追加の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が保持しているパス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）を割り当てました。このオプションはすべてのCCIDに適用でき、「クイックスタート応答」オプションとして知られており、セクション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のクイックスタートに影響を与える問題と、この文書を改善するためのコメントに影響を与える問題を特定するために、Sally Floydによる以前の研究に感謝しています。また、IETF DCCPワーキンググループ（WG）のPasi Sarolahti、Vincent Roca、Mark Allman、Michael Scharfなどからのコメントと修正も認めています。
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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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月。
[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] Floyd、S。およびE. Kohler、「データグラムの混雑制御プロトコルのプロファイル（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] Floyd、S.、Kohler、E。、およびJ. Padhye、「データグラムの混雑制御プロトコル（DCCP）混雑制御IDのプロファイル：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] Floyd、S.、Allman、M.、Jain、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] Floyd、S。およびE. Kohler、「TCP Friendly Rate Control（TFRC）：The Small-Packet（SP）Variant」、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] Floyd、S.、Handley、M.、Padhye、J。、およびJ. Widmer、「TCP Friendry Rate Control（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] Floyd、S。、およびE. Kohler、「データグラムの混雑制御プロトコルのプロファイル（DCCP）混雑ID 4：小さなパケットのTCPフレンドリーレートコントロール（TFRC-SP）、RFC 5622、2009年8月。
[RFC3344] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[RFC3344] Perkins、C.、ed。、「IPv4のIPモビリティサポート」、RFC 3344、2002年8月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775] Johnson、D.、Perkins、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] Allman、M.、Floyd、S。、およびC. Partridge、「TCPの初期ウィンドウの増加」、RFC 3390、2002年10月。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007.
[RFC4821] Mathis、M。およびJ. Heffner、「Packetization Layer Path MTU Discovery」、RFC 4821、2007年3月。
Authors' Addresses
著者のアドレス
Godred Fairhurst School of Engineering University of Aberdeen Aberdeen, AB24 3UE Scotland, UK
ゴッドレッドフェアハースト工科大学アバディーンアバディーン大学、AB24 3Uスコットランド、英国
EMail: 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
Arjuna Sathiaseelan School of Engineering School of Aberdeen Aberdeen、AB24 3Ue Scotland、英国
EMail: arjuna@erg.abdn.ac.uk
URI: http://www.erg.abdn.ac.uk/users/arjuna