RFC 6323 - Sender RTT Estimate Option for the Datagram Congestion Control Protocol (DCCP) 日本語訳

URL : https://tools.ietf.org/html/rfc6323
タイトル : RFC 6323 - データグラム輻輳制御プロトコルの送信者RTT推定オプション（DCCP）
翻訳編集 : 自動生成

Internet Engineering Task Force (IETF)                         G. Renker
Request for Comments: 6323                                  G. Fairhurst
Updates: 4342, 5622                               University of Aberdeen
Category: Standards Track                                      July 2011
ISSN: 2070-1721

                       Sender RTT Estimate Option
          for the Datagram Congestion Control Protocol (DCCP)

Abstract

抽象

This document specifies an update to the round-trip time (RTT) estimation algorithm used for TFRC (TCP-Friendly Rate Control) congestion control by the Datagram Congestion Control Protocol (DCCP). It updates specifications for the CCID-3 and CCID-4 Congestion Control IDs of DCCP.

この文書では、データグラム輻輳制御プロトコル（DCCP）によって、TFRC（TCPフレンドリーレート制御）輻輳制御のために使用往復時間（RTT）の推定アルゴリズムの更新を指定します。それはDCCPのCCID-3およびCCID-4輻輳制御IDの仕様を更新します。

The update addresses parameter-estimation problems occurring with TFRC-based DCCP congestion control. It uses a recommendation made in the original TFRC specification to avoid the inherent problems of receiver-based RTT sampling, by utilising higher-accuracy RTT samples already available at the sender.

更新は、TFRCベースのDCCPの輻輳制御で発生したパラメータ推定問題に対処するものです。これは、送信側で既に利用可能な高精度RTTサンプルを利用することによって、受信機ベースのRTTのサンプリングの固有の問題を回避するために、元のTFRC仕様で作られた勧告を使用します。

It is integrated into the feature set of DCCP as an end-to-end negotiable extension.

これは、エンド・ツー・エンドの交渉延長としてDCCPの機能セットに統合されています。

Status of This Memo

このメモのステータス

This is an Internet Standards Track document.

これは、インターネット標準化過程文書です。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6323.

このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6323で取得することができます。

著作権表示

著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Problems Caused by Sampling the RTT at the Receiver  . . . . .  4
     2.1.  List of Problems Encountered with a Real Implementation  .  4
     2.2.  Other Areas Affected by the RTT Sampling Problems  . . . .  5
       2.2.1.  Measured Receive Rate X_recv . . . . . . . . . . . . .  6
       2.2.2.  Disambiguation and Accuracy of Loss Intervals  . . . .  6
       2.2.3.  Determining Quiescence . . . . . . . . . . . . . . . .  6
       2.2.4.  Practical Considerations . . . . . . . . . . . . . . .  7
   3.  Specification  . . . . . . . . . . . . . . . . . . . . . . . .  7
     3.1.  Conventions  . . . . . . . . . . . . . . . . . . . . . . .  7
     3.2.  Options and Features . . . . . . . . . . . . . . . . . . .  7
       3.2.1.  RTT Estimate Option  . . . . . . . . . . . . . . . . .  7
       3.2.2.  Send RTT Estimate Feature  . . . . . . . . . . . . . .  9
     3.3.  Basic Usage  . . . . . . . . . . . . . . . . . . . . . . .  9
     3.4.  Receiver Robustness Measures . . . . . . . . . . . . . . . 10
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
     5.1.  Option Types . . . . . . . . . . . . . . . . . . . . . . . 11
     5.2.  Feature Numbers  . . . . . . . . . . . . . . . . . . . . . 12
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
     6.2.  Informative References . . . . . . . . . . . . . . . . . . 12

1. Introduction

1. はじめに

The Datagram Congestion Control Protocol (DCCP) [RFC4340] is a transport protocol for connection-oriented, unreliable, and congestion-controlled datagram delivery. In DCCP, an application has a choice of congestion control mechanisms, each specified by a Congestion Control Identifier (CCID; [RFC4340], Section 10).

データグラム輻輳制御プロトコル（DCCP）[RFC4340]は、接続指向の、信頼性が低く、輻輳制御データグラム配信のためのトランスポートプロトコルです。（[RFC4340]、セクション10 CCID）DCCPでは、アプリケーションは、輻輳制御機構の選択は、輻輳制御識別子によって指定された各を有します。

This document defines a Standards-Track update to the sender and receiver sides of two rate-based DCCP congestion control IDs: CCID-3 [RFC4342] and the Experimental CCID-4 variant [RFC5622].

CCID-3 [RFC4342]及び実験CCID-4変異体[RFC5622]：この文書は、二つのレートベースのDCCP輻輳制御IDの送信者と受信者側に標準トラックの更新を定義します。

Both CCIDs are based on the principles of TCP-Friendly Rate Control (TFRC) [RFC5348], which performs rate-based congestion control. Its feedback mechanism differs from that used by window-based congestion control such as in TCP. As a consequence, in TFRC the feedback may be sent less frequently (e.g., once per round-trip time). Furthermore, a measured RTT estimate is directly used as the basis for computing the (TCP-friendly) transmission rate.

両方のCCIDsは、レートベースの輻輳制御を行うTCPフレンドリーレート制御（TFRC）[RFC5348]の原理に基づいています。そのフィードバック機構は、TCPのようなウィンドウベースの輻輳制御で使用されるものとは異なります。結果として、TFRCにフィードバック（例えば、一回のラウンドトリップ時間あたり）より少ない頻度で送信されてもよいです。さらに、測定されたRTT推定値は、直接（TCP向け）の伝送レートを計算するための基礎として使用されます。

In TFRC-based protocols, packets are rate-paced over an RTT, instead of allowing them to be sent back-to-back as they could be in TCP; thus, accurate RTT estimation is important to ensure appropriate pacing at the sender.

TFRCベースのプロトコルでは、パケットは、バックツーバック、彼らはTCPになる可能性として送信する代わりに、それらを可能にする、レートのペースRTTを超えています。したがって、正確なRTT推定は、送信側で適切なペーシングを確保することが重要です。

The original specifications for CCID-3 and CCID-4, in [RFC4342] and [RFC5622], both estimate the RTT at the receiver, using an algorithm based on the cyclic 4-bit window counter of the DCCP CCVal header. The method has implications that have been observed when using applications over DCCP implementations, resulting in infrequent and inaccurate RTT measurement.

[RFC4342]及び[RFC5622]でCCID-3およびCCID-4の元の仕様は、両方ともDCCP CCValヘッダの環状4ビットウインドウカウンタに基づくアルゴリズムを使用して、受信機でのRTTを推定します。この方法は、まれと不正確なRTT測定が得られ、DCCP実装上のアプリケーションを使用するときに観察されている意味を有します。

This update addresses these RTT estimation problems by providing a solution based on a concept first recommended in [RFC5348], Section 3.2.1; i.e., to measure the RTT at the sender. That approach results in a higher reliability and frequency of samples and avoids the inherent problems of receiver-based RTT sampling discussed below.

このアップデートは、3.2.1項を最初の[RFC5348]で推奨概念に基づくソリューションを提供することによって、これらのRTT推定の問題に対処します。すなわち、送信側でRTTを測定すること。そのアプローチサンプルのより高い信頼性と頻度の結果とは、以下に説明する受信機ベースのRTTのサンプリングの固有の問題を回避します。

The document begins by analysing the encountered problems in the next section. The update is presented in Section 3. We then discuss security considerations in Section 4 and list the resulting IANA considerations in Section 5.

文書には、次のセクションで発生した問題を分析することから始まります。更新は、第3節私たちは、その後、第4節ではセキュリティ上の考慮事項について説明し、5節で結果IANAの考慮事項をリストで提示されます。

2. Problems Caused by Sampling the RTT at the Receiver

受信機でのRTTをサンプリングすることによって引き起こさ2.問題

There are at least six areas that make a TFRC receiver vulnerable to inaccuracies or absence of (receiver-based) RTT samples:

不正確または（受信系）RTTサンプルの不在に対して脆弱TFRC受信機を作る、少なくとも6つの領域があります。

o the measured sending rate, X_recv ([RFC5348], Section 6.2);

測定された送信速度、X_recv（[RFC5348]、セクション6.2）O。

o synthesis of the first loss interval ([RFC5348], Section 6.3.1);

最初の損失間隔（[RFC5348]、セクション6.3.1）のOの合成。

o disambiguation of loss events ([RFC4342], Section 10.2);

損失事象のOの曖昧性除去（[RFC4342]、セクション10.2）。

o validation of loss intervals ([RFC4342], Section 6.1);

損失間隔のO検証（[RFC4342]、セクション6.1）。

o ensuring that at least one feedback packet is sent per RTT ([RFC4342], Section 10.3);

少なくとも一つのフィードバックパケットがRTT（[RFC4342]、セクション10.3）ごとに送信されることを確実にOであり;

o determining quiescence periods ([RFC4342], Section 6.4).

休止期間（[RFC4342]、セクション6.4）を決定O。

2.1. List of Problems Encountered with a Real Implementation

2.1. 実際の実装で発生した問題の一覧

This section summarizes several years of experience using the Linux implementation of CCID-3 and CCID-4. It lists the problems encountered with receiver-based RTT sampling over real networks, in a variety of wired and wireless environments and under different link-layer conditions.

このセクションでは、CCID-3およびCCID-4のLinuxの実装を使用した経験の数年間をまとめました。これは、有線および無線環境の様々な異なるリンク層条件下での実際のネットワーク上で受信機ベースのRTTのサンプリングで遭遇した問題を、一覧表示されます。

The Linux DCCP/TFRC implementation is based on the RTT-sampling algorithm specified in [RFC4342], Section 8.1. This algorithm relies on a coarse-grained window counter (units of RTT/4), and uses packet inter-arrival times to estimate the current RTT of the network.

LinuxのDCCP / TFRCの実装は、[RFC4342]で指定されたRTTサンプリングアルゴリズムは、セクション8.1に基づいています。このアルゴリズムは、粗粒ウィンドウカウンタ（RTT / 4の単位）に依存して、ネットワークの現在のRTTを推定するために、パケット到着時間間隔を使用します。

The algorithm is effective only for packets with modulo-16 CCVal differences less than 5, due to limitations noted in Sections 8.1 and 10.3 of [RFC4342]. A CCVal difference less than 4 means sampling at sub-RTT scale; [RFC4342], Section 8.1 thus suggests differences between 2 and 4, the latter being preferable (equivalent to a full RTT). The same section limits the maximum CCVal difference between data-carrying packets to 5, in order to avoid wrap-around. As a consequence, it is not possible to determine the timing interval for adjacent packets with a CCVal difference greater than 4: such samples have to be discarded.

アルゴリズムは、セクション8.1と[RFC4342]の10.3で述べによる制限を5未満モジュロ16 CCVal差、を有するパケットのために有効です。 4未満CCVal差は、サブRTTスケールでサンプリングを意味します。 [RFC4342]、セクション8.1は、このように（完全RTTに相当）2と4の間の違いは、後者が好適であることを示唆しています。同じセクションでは、ラップアラウンドを回避するために、5にデータ伝送パケット間の最大CCVal差を制限します。その結果、4より大きいCCVal差で隣接するパケットのタイミング間隔を決定することは不可能である。そのようなサンプルが廃棄されなければなりません。

A second problem arises when there are holes in the sequence space. Because the 4-bit CCVal counter may cycle around multiple times, it is not possible to determine window-counter wrap-around whenever sequence numbers of subsequent packets are not immediately adjacent. This problem occurs when packets are delayed, reordered, or lost in the network.

配列空間の穴があるときに、第2の問題が生じます。複数回の周りに4ビットCCValカウンタ月サイクルので、後続のパケットのシーケンス番号がすぐに隣接していないときはいつでもラップアラウンドウィンドウカウンタを決定することは不可能です。パケットがネットワーク内で、遅れて並べ替え、または紛失された場合、この問題が発生します。

As a result, RTT sampling has to be paused during times of loss. However, this aggravates the problem, since the sender now requires new feedback from the receiver, but the receiver is unable to provide accurate and up-to-date information: the receiver is unable to sample the RTT, and accordingly is also unable to estimate X_recv correctly, which then in turn affects X_Bps at the sender.

その結果、RTTのサンプリングは、損失の時代に一時停止する必要があります。受信機は、RTTをサンプリングすることができず、それに応じても推定することができません：送信者が今受信機から新しいフィードバックが必要ですが、受信機は、正確かつ最新の情報を提供することができないので、これは、問題を悪化させますその後、今度は送信者にX_Bpsに影響を与える、正しくX_recv。

The third limitation arises from using inter-arrival times as representatives of network inter-packet gaps. It is well known that the inter-packet gap of packets is not constant along a network path. Furthermore, modern network interface cards do not necessarily deliver each packet at the time it is received, but rather in a bunch, to avoid overly frequent interrupts [MR97]. As a result, inter-packet arrival times may converge to zero, when subsequent packets are being delivered at virtually the same time.

第三の制限は、ネットワークパケット間ギャップの代表として到着時間間隔を使用することから生じます。よくパケットのパケット間ギャップは、ネットワーク経路に沿って一定ではないことが知られています。さらに、現代のネットワーク・インターフェース・カードは、必ずしもそれが受信される時に各パケットを配信していない、むしろ束に、過度に頻繁な割り込み[MR97]を回避します。結果として、パケット間の到着時間は、後続のパケットが実質的に同じ時間に配信されている場合、ゼロに収束することができます。

The fourth problem is that of under-sampling and thus related to the first limitation. If loss occurs while the receiver has not yet had a chance to sample the RTT, it needs to fall back to some fixed RTT constant to plug into the equation of [RFC5348], Section 6.3.1. (The sender, for example, uses a fixed value of 1 second when it is unable to obtain an initial RTT sample; see [RFC5348], Section 4.2).

第四の問題は、アンダーサンプリング及び従って第一の制限に関連するものです。受信機はまだRTTをサンプリングする機会がなかったが損失が発生した場合、それは[RFC5348]、セクション6.3.1の式にプラグインする定数いくつかの固定されたRTTにフォールバックする必要があります。（最初のRTTのサンプルを得ることができない場合、送信者は、例えば、1秒の固定値を使用して、[RFC5348]セクション4.2を参照）。

In particular, if the loss is caused by a transient condition, this fourth problem causes a subsequent deterioration of the connection (rate reduction), further aggravated by the fact that TFRC takes longer than common window-based protocols to recover from a reduction of its allowed sending rate.

損失は、過渡状態によって引き起こされる場合、特に、この第四の問題はさらにTFRCが削減から回復するために、共通のウィンドウベースのプロトコルよりも長くかかるという事実によって悪化、接続の後続の劣化（速度低下）を引き起こします許可送信レート。

Trying to smooth over these effects by imposing heavy filtering on the RTT samples did not substantially improve the situation, nor does it solve the problem of under-sampling.

RTTサンプルに重いフィルタリングを課すことによって、これらの効果を超えるスムーズしようとすると、実質的に状況を改善していない、またそれは、アンダーサンプリングの問題を解決しません。

The TFRC sender, on the other hand, is much better equipped to estimate the RTT and can do this more accurately. This is in particular due to the use of timestamps and elapsed time information ([RFC5348], Section 3.2.2), which are mandatory in CCID-3 (Sections 6 and 8.2 of [RFC4342]).

TFRCの送信者は、他の一方で、はるかに優れたRTTを推定するために装備されており、より正確にこれを行うことができます。これは、CCID-3（セクション6及び[RFC4342]の8.2）に必須でタイムスタンプと経過時間情報（[RFC5348]、セクション3.2.2）の使用に特にあります。

2.2. Other Areas Affected by the RTT Sampling Problems

2.2. RTTサンプリングの問題により影響を受けるその他の地域

Here we analyse the impact that unreliability of receiver-based RTT sampling has on the areas listed at the beginning of Section 2.

ここでは、受信機ベースのRTTのサンプリングの信頼性の欠如は、第2節の冒頭に記載されている分野に与える影響を分析します。

In addition, benefits of sender-based RTT sampling have already been pointed out in [RFC5348] and in the specification of CCID-3 at the end of Section 10.2 of [RFC4342].

また、送信者ベースのRTTのサンプリングの利点は、すでに[RFC4342]のセクション10.2の最後に[RFC5348]にし、CCID-3の仕様で指摘されています。

2.2.1. Measured Receive Rate X_recv

2.2.1. 測定されたレートX_recvを受信

A key problem is that the reliability of X_recv [RFC4342] depends directly upon the reliability and accuracy of RTT samples. This means that failures propagate from one parameter to another.

重要な問題は、X_recv [RFC4342]の信頼性はRTTサンプルの信頼性および精度に直接依存することです。これは、障害が一つのパラメータから別のものに伝播することを意味します。

Errata IDs 610 [Err610] and 611 [Err611] update [RFC4342] to use the definition of the receive rate as specified in [RFC5348].

[RFC5348]で指定されるように正誤表のID 610 [Err610]及び611 [Err611]アップデート[RFC4342]は、受信率の定義を使用します。

Having an explicit (rather than a coarse-grained) RTT estimate allows measurement of X_recv with greater accuracy and isolates failure.

RTT推定値より高い精度でX_recvの測定を可能にし、故障を分離する（粗粒ではなく）明示を有します。

An explicit RTT estimate also enables the receiver to more accurately perform the test in step (2) of [RFC4342], Section 6.2, i.e., to check whether less or more than one RTT has passed since the last feedback.

明示的なRTT推定は、より正確に[RFC4342]の（2）の工程でテストを実行するために受信機を可能にし、6.2節、すなわち、より少ないまたは複数のRTTが最後にフィードバック経過したかどうかをチェックします。

2.2.2. Disambiguation and Accuracy of Loss Intervals

2.2.2. 曖昧さ回避及び損失間隔の精度

Since a loss event is defined as one or more data packets in one RTT that are lost or marked with Explicit Congestion Notification (ECN; [RFC5348], Section 5.2), the receiver needs accurate RTT estimates to validate and accurately separate loss events. Moreover, Section 5.2 of [RFC5348] expressly indicates the sender RTT estimate is RECOMMENDED for this purpose.

損失イベントが明示的輻輳通知（ECN; [RFC5348]、セクション5.2）で失われるかマークされる1 RTT内の1つ以上のデータパケットとして定義されているため、受信機は、正確なRTTを検証し、正確別損失イベントに推定する必要があります。また、[RFC5348]のセクション5.2に明示RTT推定値は、この目的のために推奨され、送信者を示しています。

Having the sender RTT Estimate available further increases the accuracy of the information reported by the receiver. The definition of Loss Intervals in [RFC4342], Section 6.1 needs the RTT to separate the lossy parts; in particular, lossy parts spanning a period of more than one RTT are invalid.

センダRTT推定利用可能さらに増加受信機によって報告された情報の正確さを有します。 [RFC4342]での損失間隔の定義は、6.1節では、非可逆部分を分離するためにRTTを必要とします。具体的には、複数のRTTの期間にまたがる非可逆部分は無効です。

A similar benefit arises in the computation of the loss event rate: as discussed in Section 9.2 of [RFC4342], it may happen that the sender and receiver compute different loss event rates, due to differences in the available timing information. An explicit RTT estimate increases the accuracy of information available at the receiver; thus, the sender may not need to recompute the (less reliable) loss event rate reported by the receiver.

同様の利点は、損失イベント率の計算において生じる：[RFC4342]のセクション9.2で議論するように、送信者と受信者が利用可能なタイミング情報の違いによる異なる損失イベント率を計算することが起こり得ます。明示的なRTT推定値は、受信機で利用可能な情報の正確さを増加させます。したがって、送信者は受信機によって報告された（信頼性の低い）損失イベント率を再計算する必要はないかもしれません。

2.2.3. Determining Quiescence

2.2.3. 静止判定

The quiescence period is defined as max(2 * RTT, 0.2 sec) in Section 6.4 of [RFC4342]. An explicit RTT estimate avoids under- and over-estimating quiescence periods.

休止期間は、[RFC4342]のセクション6.4でMAX（2 * RTT、0.2秒）として定義されます。明示的なRTT推定値はアンダーとオーバー推定休止期間を避けることができます。

2.2.4. Practical Considerations

2.2.4. 実用的な考慮事項

Using explicit RTT estimates contributes to greater robustness and can also result in simpler implementation.

明示的なRTT推定値を使用すると、より高い堅牢性に貢献し、また、シンプルな実装をもたらす可能性があります。

First, it becomes easier to separate adjacent loss events. The 4-bit counter value wraps relatively frequently, which requires additional procedures to avoid aliasing effects.

まず、隣接する損失イベントを分離することが容易になります。 4ビットカウンタ値は、エイリアシング効果を回避するために、追加の手順を必要とする、比較的頻繁にラップ。

Second, the receiver is better able to determine when to send feedback packets. It can perform the test described in step (2) of [RFC5348], Section 6.2 more accurately. Moreover, unnecessary expiration of the nofeedback timer (as described in [RFC4342], Section 10.3) can be avoided.

第二に、受信機は、フィードバックパケットを送信するタイミングを決定しやすくなります。より正確[RFC5348]、セクション6.2のステップ（2）に記載された試験を実行することができます。また、NOFEEDBACKタイマー（[RFC4342]に記載されているように、セクション10.3）の不要満了を回避することができます。

Lastly, a sender-based RTT estimate option can be used by middleboxes to verify that a flow uses conforming end-to-end congestion control ([RFC4342], Section 10.2).

最後に、センダベースのRTT推定オプションは、フローは、エンドツーエンドの輻輳制御（[RFC4342]、セクション10.2）準拠使用していることを確認するために中間装置で使用することができます。

3. Specification

3.仕様

3.1. Conventions

3.1. 表記

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。

This document uses the conventions of [RFC5348], [RFC4340], [RFC4342], and [RFC5622].

この文書では、[RFC5348]の表記法を使用しています、[RFC4340]、[RFC4342]、および[RFC5622]。

All multi-byte field descriptions presented in this document are in network byte order (most significant byte first).

この文書のすべてのマルチバイトフィールドの説明は、ネットワークバイト順（最上位バイト）です。

3.2. Options and Features

3.2. オプションと機能

This document defines a single TFRC-specific option, RTT Estimate, described in the next subsection.

この文書は、次のサブセクションで説明した単一TFRC固有のオプション、RTT推定を定義します。

Following the guidelines in [RFC4340], Section 15, the use of the RTT Estimate Option is governed by an associated feature, Send RTT Estimate Feature. This feature is described in Section 3.2.2.

[RFC4340]、セクション15のガイドラインに続いて、RTT推定オプションの使用がRTT推定機能を送り、関連する機能によって支配されています。この機能は、3.2.2項で説明されています。

3.2.1. RTT Estimate Option

3.2.1. RTT推定オプション

The sender communicates its current RTT estimate to the receiver using an RTT Estimate Option.

送信者は、RTT推定オプションを使用して受信機に現在のRTT推定値を伝達します。

           +------+---------------+--------------+------------+
           | Type | Option Length |    Meaning   | DCCP Data? |
           +------+---------------+--------------+------------+
           |  128 |     3/4/5     | RTT Estimate |      Y     |
           +------+---------------+--------------+------------+

Table 1: The RTT Estimate Option Defined by This Document

表1：このドキュメントによって定義RTT推定オプション

Column meanings are as per [RFC4340], Section 5.8 (Table 3). This option MAY be placed in any DCCP packet, has option number 128 and a length of 3..5 bytes.

カラムの意味は[RFC4340]、セクション5.8（表3）の通りです。このオプションは任意のDCCPパケットに配置することができる、オプション番号128と3..5バイトの長さを有します。

A Sender RTT Estimate Option is valid if it satisfies one of the three following formats:

それは次の三つの形式のいずれかを満たす場合、送信者RTT推定オプションは有効です。

      +--------+--------+--------+
      |10000000|00000011|  RTT   |
      +--------+--------+--------+
       Type=128  Length=3  Estimate

      +--------+--------+--------+--------+
      |10000000|00000100|       RTT       |
      +--------+--------+--------+--------+
       Type=128  Length=4      Estimate

      +--------+--------+--------+--------+--------+
      |10000000|00000101|           RTT            |
      +--------+--------+--------+--------+--------+
       Type=128  Length=5          Estimate

The 1..3 value bytes of the option data carry the current RTT estimate of the sender, using a granularity of 1 microsecond. This allows values up to 16.7 seconds (corresponding to 0xFFFFFE) to be communicated.

オプションデータの1..3値バイトが1マイクロ秒の粒度を使用して、送信者の現在のRTT推定を運びます。これは、16.7秒（0xFFFFFEに相当）までの値を通信することを可能にします。

A sender capable of sampling at sub-microsecond granularity SHOULD round up RTT samples to the next microsecond, to avoid under-estimating the RTT.

サブマイクロ秒の粒度でサンプリングすることが可能な送信者は過小推定RTTを回避するために、次のマイクロ秒にRTTサンプルを切り上げるべきです。

The value 0xFFFFFF is reserved to indicate significant delay spikes, larger than 16.7 seconds. This is qualitative rather than quantitative information, to alert the receiver that there is a network problem (for instance, jamming on a wireless channel).

値0xFFFFFFのは16.7秒を超える大幅な遅延スパイクを示すために予約されています。これは、ネットワーク問題（例えば、無線チャネル上でジャミング）が存在することを受信機に警告するために、むしろ定量的な情報よりも定性的です。

The use of the RTT Estimate Option on networks with RTTs larger than 16.7 seconds is not specified by this document (as per Section 3.3, the sender would then always report 0xFFFFFF).

16.7秒より大きいのRTTを持つネットワーク上のRTT推定オプションの使用は（3.3節ごとに、送信者は、常に0xFFFFFFのを報告する）この文書で指定されていません。

A value of 0 indicates the absence of a valid RTT sample. The sender MUST set the value to 0 if it does not yet have an RTT estimate. RTT estimates of less than 1 microsecond MUST be reported as 1 microsecond.

0の値は、有効なRTTサンプルがないことを示します。それはまだRTT推定値を持っていない場合、送信者は0に値を設定しなければなりません。 1マイクロ秒未満のRTT推定値は、1マイクロ秒として報告しなければなりません。

The sender SHOULD select the smallest format suitable to carry the RTT estimate (i.e., less than 1 byte of leading zeroes).

送信者は、RTT推定を運ぶのに適した最小のフォーマットを選択する必要があり（すなわち、先行ゼロ未満の1バイト）。

3.2.2. Send RTT Estimate Feature

3.2.2. RTT推定機能を送ります

The Send RTT Estimate feature lets endpoints negotiate whether the sender MUST provide RTT Estimate options on its data packets.

送信RTT推定機能は、エンドポイントは、送信者がそのデータパケットのRTT推定のオプションを提供しなければならないかどうかを交渉することができます。

Send RTT Estimate has feature number 128 and is server-priority. It takes 1-byte Boolean values; values greater than 1 are reserved.

RTT推定値は機能番号128を持っており、サーバーの優先順位で送信します。これは、1バイトのブール値を取ります。 1は予約されているよりも大きな値。

    +--------+-------------------+------------+---------------+-------+
    | Number |      Meaning      | Rec'n Rule | Initial Value | Req'd |
    +--------+-------------------+------------+---------------+-------+
    |   128  | Send RTT Estimate |     SP     |       0       |   N   |
    +--------+-------------------+------------+---------------+-------+

Table 2: The Send RTT Estimate Feature Defined by This Document

表2：このドキュメントによって定義送信RTT推定機能

The column meanings are described in [RFC4340], Section 6.4.

カラムの意味は[RFC4340]、セクション6.4に記載されています。

The Send RTT Estimate feature is OPTIONAL. An extension may implement it, but this specification does not require the feature to be understood by every DCCP implementation (see [RFC4340], Section 15). The feature is off by default (initial value of 0).

送信RTT見積り機能はオプションです。拡張は、それを実施することができるが、本明細書（セクション15、[RFC4340]を参照）すべてのDCCP実装によって理解されるべき機能を必要としません。機能はデフォルト（初期値0）でオフになっています。

DCCP B sends a "Mandatory Change R(Send RTT Estimate, 1)" to require DCCP A to send RTT Estimate options as part of its data traffic (DCCP A will reset the connection if it does not understand this feature).

DCCP Bは、（それがこの機能を理解していない場合は、接続をリセットしますDCCP A）のデータトラフィックの一部として、RTT推定のオプションを送信するためにDCCP Aを必要とする「必須変更Rを（RTT推定、1を送信）」を送信します。

3.3. Basic Usage

3.3. 基本的な使い方

When the Send RTT Estimate Feature is enabled, the sender MUST provide an RTT Estimate Option on all of its Data, DataAck, Sync, and SyncAck packets. It MAY in addition provide the RTT Estimate Option on other packet types, such as DCCP-Ack. If the RTT is larger than the maximum representable value (0xFFFFFE), the sender MUST set the value of the RTT Estimate Option to 0xFFFFFF.

送信RTT推定機能が有効になっている場合、送信者はそのデータ、DataAck、同期、およびSyncAckパケットのすべてのRTT推定オプションを提供しなければなりません。これは、加えて、このようなDCCP-ACKと他のパケットタイプ、上のRTT推定オプションを提供することができます。 RTTが最大表現可能な値（0xFFFFFE）よりも大きい場合、送信者は0xFFFFFFのにRTT推定オプションの値を設定しなければなりません。

The sender MUST implement and continue to update the CCVal window counter as specified in [RFC4342], Section 8.1, even when the Send RTT Estimate Feature is on.

送信者は、実装し、送信RTT推定機能がオンになっている場合でも、[RFC4342]、セクション8.1で指定されているようCCValウィンドウカウンタを更新し続けなければなりません。

When the Send RTT Estimate Feature is enabled, the receiver MUST use the value reported by the RTT Estimate Option in all places that require an RTT (listed at the begin of Section 2). If the receiver encounters an invalid RTT Estimate Option (Section 3.2.1), it MUST reset the connection with Reset Code 5, "Option Error", where the Data 1..3 fields are set to the first 3 bytes of the offending RTT Estimate Option.

送信RTT推定機能が有効になっている場合、受信機は、（第2節の始まりに掲載されている）RTTを必要とするすべての場所でRTT推定オプションによって報告された値を使用しなければなりません。受信機が無効RTT推定オプション（3.2.1）を検出した場合、そのデータ1..3フィールドは問題RTTの最初の3バイトに設定されているリセットコード5、「オプションエラー」、との接続をリセットする必要がありますオプションを推定します。

The receiver SHOULD track the long-term RTT estimate using a moving average, such as the one specified in [RFC5348], Section 4.3. This long-term estimate is referred to as "receiver_RTT" below.

受信機は、[RFC5348]、セクション4.3で指定されたものとして移動平均を用いて長期RTT推定を追跡すべきです。この長期的な推定値は、以下の「receiver_RTT」と呼ばれています。

When the Send RTT Estimate Feature is disabled, the receiver MUST estimate the RTT as previously specified in [RFC4340], [RFC4342], and [RFC5622].

送信RTT推定機能を無効にすると、以前に[RFC4340]、[RFC4342]、および[RFC5622]で指定されるように、受信機は、RTTを推定しなければなりません。

3.4. Receiver Robustness Measures

3.4. レシーバ堅牢性対策

This subsection specifies robustness measures for the receiver when the Send RTT Estimate Feature is on.

RTT推定機能がオンになっている送るときに、このサブセクションでは、受信機のための堅牢な措置を指定します。

The 0-valued and 0xFFFFFF-valued RTT Estimate Options are both referred to as "no-number RTT options". RTT Estimate Options with values in the range of 1..0xFFFFFE are analogously called "numeric RTT options".

0値と0xFFFFFFの値RTT推定両方のオプション「ノー数RTTオプション」と呼ばれます。 1..0xFFFFFEの範囲内の値とRTT推定のオプションは、同様に「数字RTTオプション」と呼ばれています。

Until the first numeric RTT option arrives, the receiver MUST use a value of 0.5 seconds for receiver_RTT (to match the initial 2-second timeout of the TFRC nofeedback timer; see [RFC5348], Section 4.2).

最初の数値RTTオプションが到着するまで、受信機は、（TFRC NOFEEDBACKタイマの最初の2秒のタイムアウトに一致するように、[RFC5348]、セクション4.2を参照）receiver_RTT 0.5秒の値を使用しなければなりません。

If the path RTT is known, e.g., from a previous connection [RFC2140], the receiver MAY reuse the previously known path RTT value to seed its long-term RTT estimate.

経路RTTが知られている場合、例えば、以前の接続[RFC2140]から、受信機は、その長期的なRTT推定を播種するために既知の経路RTT値を再利用することができます。

The sender MAY occasionally send no-number RTT options, covering for transient changes and spurious disruptions. During these times, the receiver SHOULD continue to use its long-term receiver_RTT value.

送信者は時折、過渡変化及びスプリアス混乱のためにカバーし、無数RTTのオプションを送信することができます。これらの時間の間に、受信機は、その長期的receiver_RTT値を使用し続けなければなりません。

To avoid under-estimating the RTT in the absence of numeric options, the receiver MUST back off receiver_RTT in the following manner: if the sender supplies no-number RTT options for longer than receiver_RTT units of time, the receiver sets

下の推定数値オプションが存在しない場合にRTTを回避するために、受信機は次のようにreceiver_RTTをバックオフしなければならない：時間のreceiver_RTT単位よりも長いため、送信者の供給がない場合は、数RTTオプション、受信機のセットを

receiver_RTT = MIN(2 * receiver_RTT, t_mbi)

receiver_RTT = MIN（2 * receiver_RTT、t_mbi）

where t_mbi = 64 seconds is the maximum back-off interval ([RFC5348], Appendix A). For the next round of no-number RTT options, the updated value of receiver_RTT applies.

t_mbi 64秒=ここで、最大バックオフ間隔（[RFC5348]、付録A）です。無数RTTオプションの次のラウンドのために、receiver_RTTの更新された値が適用されます。

This back-off mechanism ensures that short-term disruptions do not have a lasting impact, whereas long-term problems will result in asymptotically high receiver_RTT values.

長期的な問題は、漸近的に高いreceiver_RTT値になり、一方、このバックオフメカニズムは、短期的な混乱は、永続的な影響を持っていないことを保証します。

To bail out from a hanging session, the receiver MAY close the connection when receiver_RTT has reached the value MAX_RTT.

吊りセッションから救済するために、受信機はreceiver_RTTが値MAX_RTTに達している接続を終えるかもしれません。

4. Security Considerations

4.セキュリティについての考慮事項

Security considerations for CCID-3 have been discussed in Section 11 of [RFC4342]; for CCID-4, these have been discussed in Section 13 of [RFC5622], referring back to the same section of [RFC4342].

CCID-3のためのセキュリティ問題は[RFC4342]のセクション11で議論されています。 CCID-4のために、これらはバック[RFC4342]の同じ部分を参照すると、[RFC5622]のセクション13で議論されてきました。

This document introduces an extension to communicate the current RTT estimate of the sender to the receiver of a TFRC communication.

この文書では、TFRC通信の受信機に送信者の現在のRTT推定値を通信するための拡張を導入します。

By altering the value of the RTT Estimate Option, it is possible to interfere with the behaviour of a flow using TFRC. In particular, since accuracy of the RTT estimate directly influences the accuracy of the measured sending rate X_recv, it would be possible to obtain either higher or lower sending rates than are warranted by the current network conditions.

RTT推定オプションの値を変更することによって、TFRCを用いたフローの動作を妨害することが可能です。 RTT推定値の精度を直接測定送信レートX_recvの精度に影響を与えるので、特に、現在のネットワーク条件によって保証されるよりも高いかまたはより低い送信レートを得ることが可能であろう。

This is only possible if an attacker is on the same path as the DCCP sender and receiver, and is able to guess valid sequence numbers. Therefore, the considerations in Section 18 of [RFC4340] apply.

これにより、攻撃者はDCCPの送信者と受信者と同じパス上にある場合にのみ可能で、かつ、有効なシーケンス番号を推測することができます。したがって、[RFC4340]のセクション18における考慮事項が当てはまります。

5. IANA Considerations

5. IANAの考慮事項

This document requests identical allocation in the dccp-ccid3- parameters and the dccp-ccid4-parameters registries.

この文書では、DCCP-ccid3-パラメータとDCCP-ccid4パラメータのレジストリで、同一の割り当てを要求します。

5.1. Option Types

5.1. オプションの種類

This document defines a single CCID-specific option (128) for communicating RTT estimates from the HC-sender to the HC-receiver. Following [RFC4340], Section 10.3, this requires an option number for the RTT Estimate Option in the range 128..191.

この文書では、RTTは、HC-受信機にHC-送信者から推定通信するための単一CCID固有のオプション（128）を定義します。 [RFC4340]、セクション10.3に続いて、これは範囲128..191でRTT推定オプションのオプション番号が必要です。

5.2. Feature Numbers

5.2. フィーチャー番号

This document defines a single CCID-specific feature number (128) for the Send RTT Estimate feature, which is located at the HC-sender. Following [RFC4340], Section 10.3, a feature number in the range 128..191 is required.

この文書では、HC-送信側に配置されている送信RTT推定機能、のための単一のCCID特有の機能番号（128）を定義します。 [RFC4340]、セクション10.3以下、範囲128..191内の特徴数が必要です。

6. References

6.参照

6.1. Normative References

6.1. 引用規格

[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月。

[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月。

[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月。

6.2. Informative References

6.2. 参考文献

[Err610] RFC Errata, Errata ID 610, RFC 4342, <http://www.rfc-editor.org>.

【Err610] RFCエラッタ、エラッタID 610、RFC 4342、<http://www.rfc-editor.org>。

[Err611] RFC Errata, Errata ID 611, RFC 4342, <http://www.rfc-editor.org>.

【Err611] RFCエラッタ、エラッタID 611、RFC 4342、<http://www.rfc-editor.org>。

[MR97] Mogul, J. and K. Ramakrishnan, "Eliminating Receive Livelock in an Interrupt-Driven Kernel", ACM Transactions on Computer Systems (TOCS), 15(3):217-252, August 1997.

"割り込み駆動カーネルにライブロックを受信排除" [MR97]モーグル、J.及びK.ラマクリシュナン、コンピュータシステム上のACMトランザクション（TOCS）、15（3）：217から252、1997年8月。

[RFC2140] Touch, J., "TCP Control Block Interdependence", RFC 2140, April 1997.

[RFC2140]タッチ、J.、 "TCP制御ブロック相互依存"、RFC 2140、1997年4月。

Authors' Addresses

著者のアドレス

Gerrit Renker University of Aberdeen School of Engineering Fraser Noble Building Aberdeen AB24 3UE Scotland

エンジニアリング・フレイザーノーブルビルアバディーンAB24 3UEスコットランドのアバディーン大学のヘリットRenker大学

EMail: gerrit@erg.abdn.ac.uk URI: http://www.erg.abdn.ac.uk

電子メール：gerrit@erg.abdn.ac.uk URI：http://www.erg.abdn.ac.uk

Godred Fairhurst University of Aberdeen School of Engineering Fraser Noble Building Aberdeen AB24 3UE Scotland

エンジニアリング・フレイザーノーブルビルアバディーンAB24 3UEスコットランドのアバディーン大学のGodred Fairhurst大学

EMail: gorry@erg.abdn.ac.uk URI: http://www.erg.abdn.ac.uk

電子メール：gorry@erg.abdn.ac.uk URI：http://www.erg.abdn.ac.uk