[要約] RFC 6556は、ネットワークのエンドユーザーの満足度を測定するためのテスト方法を提案しています。このRFCの目的は、ネットワークのパフォーマンスや品質を向上させるために、エンドユーザーの視点からのテスト手法を提供することです。
Internet Engineering Task Force (IETF) F. Baker
Request for Comments: 6556 Cisco Systems
Category: Informational April 2012
ISSN: 2070-1721
Testing Eyeball Happiness
眼球の幸福をテストします
Abstract
概要
The amount of time it takes to establish a session using common transport APIs in dual-stack networks and networks with filtering such as proposed in BCP 38 is a barrier to IPv6 deployment. This note describes a test that can be used to determine whether an application can reliably establish sessions quickly in a complex environment such as dual-stack (IPv4+IPv6) deployment or IPv6 deployment with multiple prefixes and upstream ingress filtering. This test is not a test of a specific algorithm, but of the external behavior of the system as a black box. Any algorithm that has the intended external behavior will be accepted by it.
BCP 38で提案されているようなフィルタリングを備えたデュアルスタックネットワークとネットワークで共通トランスポートAPIを使用してセッションを確立するのにかかる時間は、IPv6の展開の障壁です。このメモは、デュアルスタック（IPv4IPv6）の展開や複数のプレフィックスとアップストリームイングレスフィルタリングを使用したIPv6展開などの複雑な環境で、アプリケーションがセッションを迅速に確立できるかどうかを判断するために使用できるテストについて説明します。このテストは、特定のアルゴリズムのテストではなく、ブラックボックスとしてのシステムの外部動作のテストです。意図した外部動作を持つアルゴリズムは、それによって受け入れられます。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。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/rfc6556.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6556で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよび文書著者として特定された人。全著作権所有。
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
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントは必須です
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.
セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、簡素化されたBSDライセンスに記載されている保証なしで提供される簡略化されたBSDライセンステキストを含めます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 3
2. Measuring Eyeball Happiness . . . . . . . . . . . . . . . . . 3
2.1. Happy Eyeballs Test-Bed Configuration . . . . . . . . . . 4
2.2. Happy Eyeballs Test Procedure . . . . . . . . . . . . . . 5
2.3. Metrics for Happy Eyeballs . . . . . . . . . . . . . . . . 7
2.3.1. Metric: Session Setup Interval . . . . . . . . . . . . 7
2.3.2. Metric: Maximum Session Setup Interval . . . . . . . . 8
2.3.3. Metric: Minimum Session Setup Interval . . . . . . . . 8
2.3.4. Descriptive Metric: Attempt Pattern . . . . . . . . . 9
3. Security Considerations . . . . . . . . . . . . . . . . . . . 9
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Normative References . . . . . . . . . . . . . . . . . . . 9
5.2. Informative References . . . . . . . . . . . . . . . . . . 10
The Happy Eyeballs [RFC6555] specification notes an issue in deployed multi-prefix IPv6-only and dual-stack networks, and proposes a correction. [RFC5461] similarly looks at TCP's response to so-called "soft errors" (ICMP host and network unreachable messages), pointing out an issue and a set of possible solutions.
Happy Eyeballs [RFC6555]仕様は、展開されたMulti-Prefix IPv6のみおよびデュアルスタックネットワークの問題を指摘し、修正を提案します。[RFC5461]同様に、いわゆる「ソフトエラー」（ICMPホストと到達不能なメッセージ）に対するTCPの応答を調べ、問題と可能なソリューションのセットを指摘します。
In a dual-stack network (i.e., one that contains both IPv4 [RFC0791] and IPv6 [RFC2460] prefixes and routes), or in an IPv6-only network that uses multiple prefixes allocated by upstream providers that implement BCP 38 ingress filtering [RFC2827], the fact that two hosts that need to communicate have addresses using the same architecture does not imply that the network has usable routes connecting them, or that those addresses are useful to the applications in question. In addition, the process of establishing a session using the sockets API [RFC3493] is generally described in terms of obtaining a list of possible addresses for a peer (which will normally include both IPv4 and IPv6 addresses) using getaddrinfo() and trying them in sequence until one succeeds or all have failed. This naive algorithm, if implemented as described, has the side effect of making the worst-case delay in establishing a session far longer than human patience normally allows.
デュアルスタックネットワーク（すなわち、IPv4 [RFC0791]とIPv6 [RFC2460]のプレフィックスとルートの両方を含むもの）、またはBCP 38イングレンスろ過[RFC282727272727272727272727272727のプロバイダーによって割り当てられた複数のプレフィックスを使用するIPv6のみのプレフィックスを使用するIPv6のみのネットワークで]、通信する必要がある2つのホストが同じアーキテクチャを使用してアドレスを持っているという事実は、ネットワークがそれらを接続する使用可能なルートを持っていること、またはそれらのアドレスが問題のアプリケーションに役立つことを意味するものではありません。さらに、Sockets API [RFC3493]を使用してセッションを確立するプロセスは、getAddrinfo（）を使用してピアの可能なアドレスのリストを取得し（通常はIPv4アドレスとIPv6アドレスの両方を含む）、それらを試してみることで説明されています。シーケンスが成功するか、すべてが失敗するまで。この素朴なアルゴリズムは、記載されているように実装されている場合、人間の忍耐が通常許すよりもはるかに長くセッションを確立するのに最悪の遅延を行うという副作用を伴います。
This has the effect of discouraging users from enabling IPv6 in their equipment or content providers from offering AAAA records for their services.
これは、ユーザーが機器やコンテンツプロバイダーのIPv6がサービスにAAAAレコードを提供することを可能にすることを思いとどまらせる効果があります。
This note describes a test to determine how quickly an application can reliably open sessions in a complex environment, such as dual-stack (IPv4+IPv6) deployment or IPv6 deployment with multiple prefixes and upstream ingress filtering. This is not a test of a specific algorithm, but a measurement of the external behavior of the application and its host system as a black box. The "happy eyeballs" question is this: how long does it take an application to open a session with a server or peer, under best-case and worst-case conditions?
このメモは、複数のプレフィックスとアップストリームイングレスフィルタリングを使用したデュアルスタック（IPv4 IPv6）展開やIPv6展開など、複雑な環境でアプリケーションがセッションを確実に開くことができる速さを判断するテストについて説明します。これは、特定のアルゴリズムのテストではなく、アプリケーションとそのホストシステムの外部動作をブラックボックスとして測定することです。「ハッピーアイボール」の質問はこれです。ベストケースと最悪の条件下で、サーバーまたはピアとのセッションを開くのにどのくらいの時間がかかりますか？
The methods defined here make the assumption that the initial communication setup of many applications can be summarized by the measuring the DNS query/response and transport-layer handshaking, because no application-layer communication takes place without these steps.
ここで定義されているメソッドは、多くのアプリケーションの初期通信セットアップは、これらの手順なしでアプリケーション層通信が行われないため、DNSクエリ/応答と輸送層のハンドシェイクを測定することで要約できると仮定します。
The methods and metrics defined in this note are ideally suited for laboratory operation, as this affords the greatest degree of control to modify configurations quickly and produce consistent results.
このメモで定義されている方法とメトリックは、実験室の操作に理想的に適しています。
However, if the device under test is operated as a single user with limited query and stream generation, then there's no concern about overloading production network devices with a single "set of eyeballs". Therefore, these procedures and metrics MAY be applicable to a production network application, as long as the injected traffic represents a single user's typical traffic load, and the testers adhere to the precautions of the relevant network with respect to re-configuration of devices in production.
ただし、テスト中のデバイスがクエリとストリームの生成が制限されている単一のユーザーとして動作している場合、単一の「眼球セット」で生産ネットワークデバイスを過負荷にすることについては心配はありません。したがって、これらの手順とメトリックは、注入されたトラフィックが単一のユーザーの典型的なトラフィック負荷を表し、テスターが生産中のデバイスの再構成に関して関連するネットワークの予防措置を順守している限り、生産ネットワークアプリケーションに適用できる場合があります。。
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 measurement determines the amount of time it takes an application to establish a session with a peer in the presence of at least one IPv4 and multiple IPv6 prefixes and a variety of network behaviors. ISPs are reporting that a host (Mac OS X, Windows, Linux, FreeBSD, etc.) that has more than one address (an IPv4 and an IPv6 address, two global IPv6 addresses, etc.) may serially try addresses, allowing each TCP setup to expire, taking several seconds for each
この測定により、少なくとも1つのIPv4および複数のIPv6プレフィックスとさまざまなネットワーク動作が存在する場合、ピアとのセッションを確立するためにアプリケーションが必要な時間を決定します。ISPは、複数のアドレス（IPv4とIPv6アドレス、2つのグローバルIPv6アドレスなど）を備えたホスト（Mac OS X、Windows、Linux、FreeBSDなど）が連続的に試行され、各TCPが連続的に試行される可能性があることを報告しています。期限切れになり、それぞれ数秒かかります
attempt. There have been reports of lengthy session setup times -- in various application and OS combinations, anywhere from multi-second to half an hour -- as a result. The amount of time necessary to establish communication between two entities should be approximately the same regardless of the type of address chosen or the viability of routing in the specific network; users will expect this time to be consistent with their current experience (else, happiness is at risk).
試み。結果として、さまざまなアプリケーションとOSの組み合わせで、さまざまなアプリケーションとOSの組み合わせにおいて、長いセッションのセットアップ時間（さまざまなアプリケーションとOSの組み合わせ）が報告されています。2つのエンティティ間の通信を確立するために必要な時間は、選択したアドレスのタイプや特定のネットワーク内のルーティングの実行可能性に関係なく、ほぼ同じでなければなりません。ユーザーは、今回は現在の経験と一致することを期待します（そうでなければ、幸福は危険にさらされています）。
The configuration of equipment and applications is as shown in Figure 1.
機器とアプリケーションの構成は、図1に示すとおりです。
+--------+ | |198.51.100.0/24
|Protocol| |192.0.2.0/24 |2001:db8:0:2::/64
|Analyzer+-+2001:db8:1:0::/64 |2001:db8:1:4::/64
+--------+ |2001:db8:0:1::/64 |2001:db8:2:4::/64
| |
+-----+ | | +-----+
|Alice+-+ +-+ Bob |
+-----+ | +-------+ +-------+ | +-----+
+-+Router1| |Router2+-+
+-----+ | +-----+-+ +-+-----+ |
| DNS +-+ | | |
+-----+ | -+------+- |
| 203.0.113.0/24 |
| 2001:db8:0:3::/64 |
Figure 1: Generic Test Environment
図1：一般的なテスト環境
Alice is the unit being measured, the computer running the process that will establish a session with Bob for the application in question. DNS is represented in the diagram as a separate system, as is the protocol analyzer that will watch Alice's traffic. This is not absolutely necessary; if one computer can run tcpdump and a DNS server process -- and for that matter, can subsume the routers -- that is acceptable. The units are separated in the test for purposes of clarity.
アリスは測定されているユニットであり、問題のアプリケーションのためにボブとのセッションを確立するプロセスを実行しているコンピューターです。DNSは、アリスのトラフィックを視聴するプロトコルアナライザーと同様に、図で別のシステムとして表されています。これは絶対に必要ではありません。1つのコンピューターがTCPDUMPとDNSサーバープロセスを実行でき、そのためにルーターを包むことができる場合、それは許容されます。ユニットは、明確さの目的でテストで分離されています。
On each test run, configuration is performed in Router 1 to permit only one route to work. There are various ways this can be accomplished, including but not limited to installing:
各テスト実行では、ルーター1で構成が実行され、1つのルートのみが機能します。インストールを含むがこれらに限定されないさまざまな方法があります。
o a filter that drops datagrams to Bob resulting in an ICMP "administratively prohibited",
o データグラムをBOBにドロップし、ICMPが「管理上禁止」されるフィルター、
o a filter that silently drops datagrams to Bob,
o 静かにデータグラムをボブにドロップするフィルター、
o a null route or removing the route to one of Bob's prefixes, resulting in an ICMP "destination unreachable", and
o nullルートまたはボブの接頭辞の1つへのルートを削除して、ICMP「宛先が到達できない」、そして
o a middleware program that responds with a TCP RST.
o TCP Rで応答するミドルウェアプログラム。
o Path MTU issues
o PATH MTUの問題
The Path MTU Discovery [RFC1191] [RFC1981] matter requires some explanation. With IPv6, and with IPv4, when "Do Not Fragment" is set, a router with a message too large for an interface discards it and replies with an ICMPv4 "Destination Unreachable: Datagram Too Big" or ICMPv6 "Packet Too Big". If this packet is lost, the source doesn't know what size to fragment to and has no indication that fragmentation is required. A configuration for this scenario would set the MTU on 203.0.113.0/24 or 2001:db8:0:3::/64 to the smallest allowed by the address family (576 or 1280) and disable generation of the indicated ICMP message. Note that [RFC4821] is intended to address these issues.
PATH MTU Discovery [RFC1191] [RFC1981]問題には、何らかの説明が必要です。IPv6の場合、およびIPv4を使用すると、「Do not Fragment」が設定されている場合、インターフェイスには大きすぎるメッセージを備えたルーターがそれを破棄し、ICMPV4「宛先なしの宛先：データグラムが大きすぎる」またはICMPV6「パケットが大きすぎる」で返信します。このパケットが失われた場合、ソースはどのサイズに断片化するかを知らず、断片化が必要であることを示すことはありません。このシナリオの構成により、MTUは203.0.113.0/24または2001：DB8：0：3 ::/64に、住所ファミリー（576または1280）が最小限にし、指定されたICMPメッセージの生成を無効にします。[RFC4821]はこれらの問題に対処することを目的としていることに注意してください。
The tester should try different methods to determine whether variances in this configuration make a difference in the test. For example, one might find that the application under test responds differently to a TCP RST than to a silent packet loss. Each of these scenarios should be tested; if doing so is too difficult, the most important is the case of silent packet loss, as it is the worst case.
テスターは、この構成の分散がテストに違いをもたらすかどうかを判断するために、さまざまな方法を試してみる必要があります。たとえば、テスト中のアプリケーションは、サイレントパケットの損失とは異なるTCP RSTに対して異なる応答を異なることがわかります。これらの各シナリオはテストする必要があります。そうすることが難しすぎる場合、最も重要なのは、最悪の場合であるため、サイレントパケット損失の場合です。
Consider a network as described in Section 2.1. Alice and Bob each have a set of one or more IPv4 and two or more IPv6 addresses. Bob's are in DNS, where Alice can find them; Alice's and others' may be there as well, but they are not relevant to the test. Routers 1 and 2 are configured to route the relevant prefixes. Different measurement trials revise an access list or null route in Router 1 that would prevent traffic Alice->Bob using each of Bob's addresses. If Bob has a total of N addresses, we run the measurement at least N times, permitting exactly one of the addresses to enjoy end-to-end communication each time. If the DNS service randomizes the order of the addresses, this may not result in a test requiring establishment of a connection to all of the addresses; in this case, the test will have to be run repeatedly until in at least one instance a TCP SYN or its equivalent is seen for each relevant address. The tester either should flush the resolver cache between iterations, to force repeated DNS resolution, or should wait for at least the DNS RR TTL on each resource record. In the latter case, the tester should also observe DNS re-resolving; if not, the application is not correctly using DNS.
セクション2.1で説明されているネットワークを検討してください。アリスとボブにはそれぞれ、1つ以上のIPv4と2つ以上のIPv6アドレスのセットがあります。ボブはDNSにあり、アリスはそれらを見つけることができます。アリスや他の人もそこにあるかもしれませんが、テストには関係ありません。ルーター1と2は、関連するプレフィックスをルーティングするように構成されています。さまざまな測定試験では、Router 1のアクセスリストまたはNULLルートを修正します。ボブに合計nアドレスがある場合、測定を少なくともn回実行し、毎回エンドツーエンドのコミュニケーションを楽しむアドレスの1つを許可します。 DNSサービスがアドレスの順序を無作為化した場合、これはすべてのアドレスへの接続を確立する必要があるテストにならない場合があります。この場合、テストは、少なくとも1つのインスタンスで、関連する各アドレスでTCP synまたはその同等物が見られるまで繰り返し実行する必要があります。テスターは、繰り返しの間にリゾルバーキャッシュを洗い流し、繰り返しDNS解像度を強制するか、各リソースレコードで少なくともDNS RR TTLを待つ必要があります。後者の場合、テスターはDNSの再解凍も観察する必要があります。そうでない場合、アプリケーションはDNSを正しく使用していません。
This specification assumes common LAN technology with no competing traffic and nominal propagation delays, so that they are not a factor in the measurement.
この仕様は、競合するトラフィックや名目上の伝播遅延がない一般的なLANテクノロジーを想定しているため、測定の要因ではありません。
The objective is to measure the amount of time required to establish a session. This includes the time from Alice's initial DNS request through one or more attempts to establish a session to the session being established, as seen in the LAN trace. The simplest way to measure this will be to put a traffic analyzer on Alice's point of attachment and capture the messages exchanged by Alice.
目的は、セッションを確立するのに必要な時間を測定することです。これには、LANトレースで見られるように、確立されているセッションのセッションを確立するための1つ以上の試行によるアリスの最初のDNSリクエストからの時間が含まれます。これを測定する最も簡単な方法は、アリスの添付ファイルのポイントにトラフィックアナライザーを置き、アリスが交換したメッセージをキャプチャすることです。
DNS Server Alice Bob
| | |
1. |<--www.example.com A------| |
2. |<--www.example.com AAAA---| |
3. |---198.51.100.1---------->| |
4. |---2001:db8:0:2::1------->| |
5. | | |
6. | |--TCP SYN, IPv6--->X |<***********
7. | |--TCP SYN, IPv6--->X | |
8. | |--TCP SYN, IPv6--->X | TCP 3wHS
9. | | | Time
10. | |--TCP SYN, IPv4------->|(any family)
11. | |<-TCP SYN+ACK, IPv4----| |
12. | |--TCP ACK, IPv4------->|<***********
Figure 2: Message Flow Using TCP
図2：TCPを使用したメッセージフロー
In a TCP-based application (Figure 2), that would be from the DNS request (line 1) through the first completion of a TCP three-way handshake (line 12), which is abbreviated "3wHS" above.
TCPベースのアプリケーション（図2）では、DNSリクエスト（1行目）から、上記の「3whs」と略されるTCP 3方向握手（12行目）の最初の完了までです。
DNS Server Alice Bob
| | |
1. |<--www.example.com A------| |
2. |<--www.example.com AAAA---| |
3. |---198.51.100.1---------->| |
4. |---2001:db8:0:2::1------->| |
5. | | |
6. | |--UDP Request, IPv6-->X|<---------
7. | |--UDP Request, IPv6-->X| first
8. | |--UDP Request, IPv6-->X| request/
9. | | | response
10. | |--UDP Request, IPv4--->| success
11. | |<-UDP Response, IPv4---|<---------
Figure 3: Message Flow Using UDP
図3：UDPを使用したメッセージフロー
In a UDP-based application (Figure 3), that would be from the DNS request (line 1) through one or more UDP Requests (lines 6-10) until a UDP Response is seen (line 11).
UDPベースのアプリケーション（図3）では、UDP応答（11行目）が見られるまで、DNS要求（1行目）から1つ以上のUDP要求（6〜10行目）からのものです。
When using other transports, the methodology will have to be specified in context; it should measure the same event.
他のトランスポートを使用する場合、方法論はコンテキストで指定する必要があります。同じイベントを測定する必要があります。
The measurements taken are the duration of the interval from the initial DNS request until the session is seen to have been established, as described in Section 2.2. We are interested in the shortest and longest durations (which will most likely be those that send one SYN and succeed and those that send a SYN to each possible address before succeeding in one of the attempts), and the pattern of attempts sent to different addresses. The pattern may be simply to send an attempt every <time interval>, or it may be more complex; as a result, this is in part descriptive.
セクション2.2で説明されているように、行われた測定値は、初期DNS要求からセッションが確立されるまで見られるまでの間隔の期間です。私たちは、最短および最も長い期間（おそらく1つのSynを送信して成功したものと、試みの1つで成功する前に各住所にSynを送信するもの）と、異なるアドレスに送信された試みのパターンに興味があります。。パターンは、単に<タイムインターバル>ごとに試行を送信することである場合もあれば、より複雑な場合もあります。その結果、これは部分的に説明的です。
ALL measurement events on the sending and receiving of messages SHALL be observed at Alice's attachment point and timestamps SHOULD be applied upon reception of the last bit of the IP information field. Use of an alternate timing reference SHALL be noted.
メッセージの送信と受信に関するすべての測定イベントは、アリスの添付ファイルポイントで観察され、タイムスタンプはIP情報フィールドの最後のビットを受信するときに適用する必要があります。代替タイミング参照の使用に注意する必要があります。
Name: Session Setup Interval
名前：セッションのセットアップ間隔
Description: The session setup interval MUST be the time beginning with the first DNS query sent (observed at Alice's attachment) and ending with successful transport connection establishment (as indicated in line 12 of Figure 2 and line 11 of Figure 3). This interval is defined as the session setup interval.
説明：セッションのセットアップ間隔は、送信された最初のDNSクエリ（アリスの添付ファイルで観察）から始まり、輸送接続の確立が成功したことから始まる時間でなければなりません（図2の行と図3の行11に示すように）。この間隔は、セッションのセットアップ間隔として定義されます。
This test will be run several times, once for each possible combination of destination address (configured on Bob) and failure mode (configured on Router 1).
このテストは、宛先アドレス（BOBで構成）と故障モード（ルーター1で構成）の可能な組み合わせごとに1回、数回実行されます。
Methodology: In the LAN analyzer trace, note the times of the initial DNS request and the confirmation that the session is open as described in Section 2.2. If the session is not successfully opened, possibly due to Alice aborting the attempt, the Session Setup Interval is considered to be infinite.
方法論：LANアナライザートレースでは、最初のDNSリクエストの時間と、セクション2.2で説明されているようにセッションが開いていることの確認に注意してください。おそらくアリスが試みを中止したためにセッションが正常に開かれていない場合、セッションのセットアップ間隔は無限であると見なされます。
Units: Session setup time is measured in milliseconds.
ユニット：セッションのセットアップ時間はミリ秒で測定されます。
Measurement Point(s): The measurement point is at Alice's LAN interface, both sending and receiving, observed using a program such as tcpdump running on Alice or an external analyzer.
測定ポイント：測定ポイントは、アリスの両方のLANインターフェイスで、Aliceまたは外部アナライザーで実行されているTCPDUMPなどのプログラムを使用して、送信および受信の両方で観察されます。
Timing: The measurement program or external analyzer MUST run for a duration sufficient to capture the entire message flow as described in Section 2.2. Measurement precision MUST be sufficient to maintain no more than 0.1 ms error over a 60-second interval. 1 part per million (ppm) precision would suffice.
タイミング：測定プログラムまたは外部アナライザーは、セクション2.2で説明されているように、メッセージフロー全体をキャプチャするのに十分な期間実行する必要があります。測定精度は、60秒の間隔で0.1 ms以下の誤差を維持するのに十分でなければなりません。1部あたり1部（ppm）の精度で十分です。
Name: Maximum Session Setup Interval
名前：最大セッションのセットアップ間隔
Description: The maximum session setup interval is the longest period of time observed for the establishment of a session as described in Section 2.3.1.
説明：最大セッションのセットアップ間隔は、セクション2.3.1で説明されているセッションの確立で観察される最長期間です。
Methodology: See Session Setup Interval.
方法論：セッションのセットアップ間隔を参照してください。
Units: Session setup time is measured in milliseconds.
ユニット：セッションのセットアップ時間はミリ秒で測定されます。
Measurement Point(s): See Session Setup Interval.
測定ポイント：セッションのセットアップ間隔を参照してください。
Timing: The measurement program or external analyzer MUST run for a duration sufficient to capture the entire message flow as described in Section 2.2. Measurement precision MUST be sufficient to maintain no more than 0.1 ms error over a 60-second interval. 1 ppm precision would suffice.
タイミング：測定プログラムまたは外部アナライザーは、セクション2.2で説明されているように、メッセージフロー全体をキャプチャするのに十分な期間実行する必要があります。測定精度は、60秒の間隔で0.1 ms以下の誤差を維持するのに十分でなければなりません。1 ppm精度で十分です。
Name: Minimum Session Setup Interval
名前：最小セッションのセットアップ間隔
Description: The minimum session setup interval is the shortest period of time observed for the establishment of a session.
説明：最小セッションのセットアップ間隔は、セッションの確立で観察される最短期間です。
Methodology: See Session Setup Interval.
方法論：セッションのセットアップ間隔を参照してください。
Units: Session setup time is measured in milliseconds.
ユニット：セッションのセットアップ時間はミリ秒で測定されます。
Measurement Point(s): See Session Setup Interval.
測定ポイント：セッションのセットアップ間隔を参照してください。
Timing: The measurement program or external analyzer MUST run for a duration sufficient to capture the entire message flow as described in Section 2.2. Measurement precision MUST be sufficient to maintain no more than 0.1 ms error over a 60-second interval. 1 ppm precision would suffice.
タイミング：測定プログラムまたは外部アナライザーは、セクション2.2で説明されているように、メッセージフロー全体をキャプチャするのに十分な期間実行する必要があります。測定精度は、60秒の間隔で0.1 ms以下の誤差を維持するのに十分でなければなりません。1 ppm精度で十分です。
Name: Attempt pattern
名前：試行パターン
Description: The Attempt Pattern is a description of the observed pattern of attempts to establish the session. In simple cases, it may be something like "Initial TCP SYNs to a new address were observed every <so many> milliseconds"; in more complex cases, it might be something like "Initial TCP SYNs in IPv6 were observed every <so many> milliseconds, and other TCP SYNs using IPv4 were observed every <so many> milliseconds, but the two sequences were independent." It may also comment on retransmission patterns if observed.
説明：試行パターンは、セッションを確立しようとする試みの観察されたパターンの説明です。単純な場合、「新しいアドレスに対する初期TCP synsがすべて<非常に多くのミリ秒秒」のようなものである可能性があります。より複雑なケースでは、「IPv6の初期TCP Synsがすべての<非常に多くのミリ秒秒が観察され、IPv4を使用した他のTCP synがすべて<非常に多くのミリ秒>ミリ秒が観察されましたが、2つのシーケンスは独立していました。」また、観察された場合、再送信パターンについてもコメントする場合があります。
Methodology: The traffic trace is analyzed to determine the pattern of initiation.
方法論：トラフィックトレースを分析して、開始のパターンを決定します。
Units: milliseconds.
ユニット：ミリ秒。
Measurement Point(s): The measurement point is at Alice's LAN interface, observed using a program such as tcpdump running on Alice or an external analyzer.
測定ポイント：測定ポイントは、アリスのLANインターフェイスにあり、アリスまたは外部アナライザーで実行されているTCPDUMPなどのプログラムを使用して観察されます。
Timing: The measurement program or external analyzer MUST run for a duration sufficient to capture the entire message flow as described in Section 2.2. Measurement precision MUST be sufficient to maintain no more than 0.1 ms error over a 60-second interval. 1 ppm precision would suffice.
タイミング：測定プログラムまたは外部アナライザーは、セクション2.2で説明されているように、メッセージフロー全体をキャプチャするのに十分な期間実行する必要があります。測定精度は、60秒の間隔で0.1 ms以下の誤差を維持するのに十分でなければなりません。1 ppm精度で十分です。
This note doesn't address security-related issues.
このメモは、セキュリティ関連の問題に対処していません。
This note was discussed with Dan Wing, Andrew Yourtchenko, and Fernando Gont. In the Benchmark Methodology Working Group, Al Morton, David Newman, Sarah Banks, and Tore Anderson made comments.
このメモは、ダン・ウィング、アンドリュー・Yourtchenko、およびFernando Gontと議論されました。ベンチマークの方法論ワーキンググループでは、アル・モートン、デビッド・ニューマン、サラ・バンクス、そしてアンダーソンがコメントしました。
[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月。
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with Dual-Stack Hosts", RFC 6555, April 2012.
[RFC6555] Wing、D。and A. Yourtchenko、「ハッピーアイボール：デュアルスタックホストでの成功」、RFC 6555、2012年4月。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191] Mogul、J。およびS. Deering、「Path MTU Discovery」、RFC 1191、1990年11月。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981] McCann、J.、Deering、S。、およびJ. Mogul、「IPバージョン6のPath MTU Discovery」、RFC 1981、1996年8月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「Internet Protocol、Version 6（IPv6）仕様」、RFC 2460、1998年12月。
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2827]ファーガソン、P。およびD.セニー、「ネットワークイングレスフィルタリング：IPソースアドレススプーフィングを採用するサービス拒否攻撃の敗北」、BCP 38、RFC 2827、2000年5月。
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, February 2003.
[RFC3493] Gilligan、R.、Thomson、S.、Bound、J.、McCann、J。、およびW. Stevens、「IPv6の基本ソケットインターフェイス拡張」、RFC 3493、2003年2月。
[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月。
[RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, February 2009.
[RFC5461] Gont、F。、「ソフトエラーに対するTCPの反応」、RFC 5461、2009年2月。
Author's Address
著者の連絡先
Fred Baker Cisco Systems Santa Barbara, California 93117 USA
フレッドベイカーシスコシステムサンタバーバラ、カリフォルニア93117 USA
EMail: fred@cisco.com