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

原文URL : https://datatracker.ietf.org/doc/html/rfc6323
タイトル : RFC 6323 - Datagram混雑制御プロトコル（DCCP）の送信者RTT見積もりオプション
翻訳編集 : 自動生成

[要約] RFC 6323は、DCCPにおける送信者のRTT推定オプションに関する規格です。このRFCの目的は、DCCPのパフォーマンスを向上させるために、送信者が正確なRTT推定を行うための仕組みを提供することです。

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)

Datagram輻輳制御プロトコル（DCCP）の送信者RTT推定オプション

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.

このドキュメントは、TFRC（TCPフレンドリーレート制御）の混雑制御に使用されるラウンドトリップ時間（RTT）推定アルゴリズムの更新を、Datagram混雑制御プロトコル（DCCP）による混雑制御を指定しています。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混雑制御で発生するパラメーター推定の問題に対処します。元のTFRC仕様で作成された推奨事項を使用して、送信者ですでに利用可能な高精度のRTTサンプルを利用することにより、受信機ベースのRTTサンプリングの固有の問題を回避します。

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.

このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6323で取得できます。

著作権表示

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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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).

Datagramうっ血コントロールプロトコル（DCCP）[RFC4340]は、接続指向、信頼性の低い、および混雑制御データグラムの配信のためのトランスポートプロトコルです。DCCPでは、アプリケーションには輻輳制御メカニズムの選択があり、それぞれが輻輳制御識別子（CCID; [RFC4340]、セクション10）で指定されています。

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].

このドキュメントでは、2つのレートベースのDCCP混雑制御IDの送信者と受信者側の標準トラック更新を定義します：CCID-3 [RFC4342]および実験的CCID-4バリアント[RFC5622]。

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.

両方のCCIDは、速度ベースの混雑制御を実行するTCPフレンドリーレート制御（TFRC）[RFC5348]の原則に基づいています。そのフィードバックメカニズムは、TCPなどのウィンドウベースの混雑制御によって使用されるものとは異なります。結果として、TFRCでは、フィードバックの頻度が低下する場合があります（たとえば、往復時間ごとに1回）。さらに、測定された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の元の仕様は、DCCPCCVALヘッダーの環状4ビットウィンドウカウンターに基づいたアルゴリズムを使用して、レシーバーのRTTを推定します。この方法には、DCCP実装を介してアプリケーションを使用するときに観察された意味があり、結果としてまれで不正確なRTT測定が生じます。

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.

この更新は、[RFC5348]、セクション3.2.1で最初に推奨される概念に基づいたソリューションを提供することにより、これらの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のセキュリティ上の考慮事項について説明し、結果のIANAに関する考慮事項をセクション5にリストします。

2. Problems Caused by Sampling the RTT at the Receiver

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

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

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

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

o 測定された送信率X_RECV（[RFC5348]、セクション6.2）;

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

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

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);

o RTTごとに少なくとも1つのフィードバックパケットが送信されるようにします（[RFC4342]、セクション10.3）。

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

o 静止期間の決定（[RFC4342]、セクション6.4）。

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]、セクション8.1で指定されたRTTサンプリングアルゴリズムに基づいています。このアルゴリズムは、粗粒のウィンドウカウンター（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.

このアルゴリズムは、[RFC4342]のセクション8.1および10.3に記載されている制限により、5未満のModulo-16 CCValの差を持つパケットにのみ有効です。4未満のCCValの差は、サブRTTスケールでのサンプリングを意味します。[RFC4342]、セクション8.1は、2と4の違いを示唆しており、後者は好ましい（完全なRTTに相当）。同じセクションでは、ラップアラウンドを避けるために、データキャリーパケット間の最大CCValの差を5に制限します。結果として、隣接するパケットのタイミング間隔を決定することはできません。CCValの差は4を超えています。そのようなサンプルを破棄する必要があります。

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サンプリングは、喪失時に一時停止する必要があります。ただし、送信者は受信機からの新しいフィードバックが必要になるため、これは問題を悪化させますが、受信機は正確かつ最新の情報を提供することができません。X_Recvは正しく、次に送信者のX_BPSに影響します。

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.

3番目の制限は、ネットワーク間パケットのギャップの代表として到着間時間を使用することから生じます。パケットのパケット間ギャップがネットワークパスに沿って一定ではないことはよく知られています。さらに、最新のネットワークインターフェイスカードは、受け取った時点で各パケットを必ずしも配信するのではなく、むしろ頻繁に頻繁に中断することを避けるために束になります[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).

4番目の問題は、サンプリング不足の問題であり、最初の制限に関連しています。レシーバーがまだRTTをサンプリングする機会がなかった間に損失が発生した場合、[RFC5348]の方程式に差し込むために固定RTT定数に戻る必要があります。セクション6.3.1。（たとえば、送信者は、初期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.

特に、損失が一時的な状態によって引き起こされる場合、この4番目の問題は、接続のその後の劣化（レート削減）を引き起こします。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を推定するためにはるかに優れており、これをより正確に行うことができます。これは、特にタイムスタンプの使用と経過時間情報（[RFC5348]、セクション3.2.2）のためであり、CCID-3で必須です（[RFC4342]のセクション6および8.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.

ここでは、セクション2の冒頭にリストされている領域に受信機ベースのRTTサンプリングの信頼性が低いという影響を分析します。

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サンプリングの利点は、[RFC5348]および[RFC4342]のセクション10.2の最後にある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].

Errata IDS 610 [ERR610]および611 [ERR611]更新[RFC4342]を更新して、[RFC5348]で指定されている受信率の定義を使用します。

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]、セクション6.2のステップ（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.

損失イベントは、1つのRTTの1つまたは複数のデータパケットとして定義されているため、明示的な輻輳通知（ECN; [RFC5348]、セクション5.2）で失われたりマークされたりするため、受信者は正確な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で最大（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]のステップ（2）で説明されているテストを実行できます。セクション6.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].

「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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推定オプションは、次の3つの形式のいずれかを満たす場合に有効です。

      +--------+--------+--------+
      |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推定機能はオプションです。拡張機能はそれを実装する場合がありますが、この仕様では、すべてのDCCP実装によって理解される機能を必要としません（[RFC4340]、セクション15を参照）。機能はデフォルトでオフになっています（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は、「必須の変更r（RTT推定値を送信）」を送信します。DCCPAにデータトラフィックの一部としてRTT推定オプションを送信するように要求します（DCCP Aは、この機能を理解していない場合は接続をリセットします）。

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推定機能が有効になっている場合、送信者は、すべてのデータ、DataSack、Sync、およびSyncackパケットにRTT推定オプションを提供する必要があります。さらに、DCCP-CACKなどの他のパケットタイプにRTT推定オプションを提供する場合があります。RTTが最大表現可能な値（0xfffffe）よりも大きい場合、送信者はRTT推定オプションの値を0xffffffに設定する必要があります。

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.

送信者は、[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推定機能が有効になっている場合、受信者はRTT（セクション2の開始にリストされている）を必要とするすべての場所でRTT推定オプションによって報告された値を使用する必要があります。受信者が無効なRTT推定オプション（セクション3.2.1）に遭遇した場合、コード5「オプションエラー」との接続をリセットする必要があります。ここで、データ1..3フィールドは、違反RTTの最初の3バイトに設定されます。見積もりオプション。

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推定オプションは、どちらも「NONUMBER 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オプションが到着するまで、受信者は受信者_RTTに対して0.5秒の値を使用する必要があります（TFRC nofeedbackタイマーの最初の2秒のタイムアウトと一致します。[RFC5348]、セクション4.2を参照）。

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.

たとえば、以前の接続[RFC2140]からパスRTTがわかっている場合、受信者は以前に既知のパス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.

送信者は、一時的な変化や偽の混乱をカバーする、Nommumber 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)

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の場合、これらは[RFC5622]のセクション13で説明されており、[RFC4342]の同じセクションを参照しています。

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

このドキュメントでは、送信者の現在のRTT推定値をTFRC通信の受信者に通信するための拡張機能を紹介します。

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-Parametersレジストリで同じ割り当てを要求します。

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.

このドキュメントでは、HC-SenderからHC-ReceiverにRTT推定値を伝えるための単一の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] 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月。

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

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

6.2. Informative References

6.2. 参考引用

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

[ERR610] RFC Errata、Errata ID 610、RFC 4342、<http://www.rfc-editor.org>。

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

[ERR611] RFC Errata、Errata 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] Mogul、J。およびK. Ramakrishnan、「割り込み駆動型カーネルでのリベロックを排除する」、コンピューターシステム（TOC）のACMトランザクション、15（3）：217-252、1997年8月。

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

[RFC2140] Touch、J。、「TCP制御ブロック相互依存」、RFC 2140、1997年4月。

Authors' Addresses

著者のアドレス

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

ゲリットレンカーアバディーン大学工学部フレイザーノーブルビルアバディーンAB24 3Uスコットランド

   EMail: 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 3Uスコットランド

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