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展開に対する障壁です。このノートは、アプリケーションが確実にそのような複数のプレフィックスと上流イングレスフィルタリングを有するデュアルスタック（IPv4の+ IPv6）の配備または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によって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 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.
ハッピー眼球[RFC6555]仕様は、展開、マルチプレフィックス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のイングレスフィルタリングを実装上流プロバイダによって割り当てられた複数のプレフィックスを使用してIPv6のみのネットワークに[RFC2827 ]、通信するために必要な2つのホストがネットワークにそれらを接続する使用可能な経路を有すること、またはこれらのアドレスは、当該アプリケーションに有用であることを意味するものではない同じアーキテクチャを使用してアドレスを有するという事実。加えて、ソケットAPI [RFC3493]を使用してセッションを確立するプロセスは、一般的に（通常はIPv4およびIPv6アドレスの両方を含んでなる）ピアの可能なアドレスのリストを取得するのgetaddrinfo（）を使用し、それらをしようとの観点から説明されていますシーケンス1が成功またはすべてが失敗したまで。この素朴なアルゴリズムは、説明するように実装されている場合、はるかに長い人間の忍耐が正常にできますよりも、セッションを確立する上で最悪の場合の遅延を作るの副作用があります。
This has the effect of discouraging users from enabling IPv6 in their equipment or content providers from offering AAAA records for their services.
これは、彼らのサービスのためのAAAAレコードを提供するから、自社の機器やコンテンツプロバイダにIPv6を有効にするからユーザーを落胆させる効果を有します。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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 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).
この測定は、少なくとも1つのIPv4と複数のIPv6プレフィックスの存在およびネットワークの動作の様々なピアとのセッションを確立するアプリケーションに要する時間の量を決定します。 ISPは、ホストがする（Mac OS Xは、Windowsは、Linuxの、FreeBSDの、など）複数のアドレス（IPv4およびIPv6アドレス、二つのグローバルIPv6アドレスなど）を持つ直列TCPをできるように、アドレスを試すことが報告されています各試みのために数秒を取って、有効期限が切れるように設定。どこでもマルチ秒から半時間に、様々なアプリケーションと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で実行されます。インストールを含むがこれらに限定されない、これを達成することができ、さまざまな方法があります：
o a filter that drops datagrams to Bob resulting in an ICMP "administratively prohibited",
O ICMPもたらすボブにデータグラムをドロップフィルタは、「管理上禁止します」、
o a filter that silently drops datagrams to Bob, o a null route or removing the route to one of Bob's prefixes, resulting in an ICMP "destination unreachable", and
サイレントヌルルートOまたはICMP「宛先到達不能」で得られたボブのプレフィックスのいずれかへのルートを除去、ボブにデータグラムをドロップフィルタ、O、及び
o a middleware program that responds with a TCP RST.
TCP RSTで応答ミドルウェアプログラムO。
o Path MTU issues
Oパス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.
パスMTUディスカバリ[RFC1191] [RFC1981]の問題は、いくつかの説明が必要です。 IPv6では、および設定されている「フラグメントしない」はIPv4と、インターフェースに対して大きすぎるメッセージを持つルータは、それを破棄し、ICMPv4の「宛先到達不能：データグラムが大きすぎます」と返信またはICMPv6の「パケット過大」。このパケットが失われた場合、ソースはに断片化するどのようなサイズを知っていると断片化が必要であること兆候を持っていません。このシナリオの構成は203.0.113.0/24又は2001年MTUを設定します：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.
テスターは、この構成の変動は、テストの違いを作るかどうかを判断するためにさまざまな方法を試してみてください。例えば、1は、テスト対象のアプリケーションがより静かパケットロスに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節で説明したようにネットワークを考えてみましょう。アリスとボブそれぞれが一つ以上のIPv4および二つ以上のIPv6アドレスのセットを有します。ボブのアリスがそれらを見つけることができますDNS、です。アリスの他はそこにもなるかもしれないが、彼らはテストには関係ありません。ルータ1及び2は、ルートに関連するプレフィックスを構成しています。異なる測定試験では、ボブのアドレスのそれぞれを使用してトラフィックAlice->ボブを妨げるルータ1でのアクセスリストまたはNullルートを修正します。ボブは、N個のアドレスの合計を持っている場合、我々は、エンドツーエンドの通信を毎回楽しむために正確に一つのアドレスを許可する、少なくともN回の測定を実行します。 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）において、すなわち、上記「3WHS」と略記されるTCPスリーウェイハンドシェイク（ライン12）の最初の完了を介してDNSリクエスト（ライン1）からなるであろう。
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応答が見られるまで、一つ以上のUDP要求（ライン6~10）を介してDNSリクエスト（ライン1）からなり、UDPベースのアプリケーション（図3）では、（ライン11）。
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を送信するものと、成功するとの試みの一つに成功する前に、各可能なアドレスへの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.
説明：セッションセットアップ区間は時間（図2のライン12と図3の線11で示されるように）（アリスのアタッチメントで観察された）送信された最初のDNSクエリで始まり、成功したトランスポート接続の確立で終了していなければなりません。この間隔は、セッション設定間隔として定義されます。
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).
この試験は（ボブに構成された）宛先アドレスと（ルータ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アナライザのトレースでは、2.2節で説明したように、セッションが開いていることを最初のDNS要求と確認の時間に注意してください。セッションが正常に試行を中止おそらくアリスに、開かれていない場合は、セッション設定間隔は無限であると考えられています。
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インタフェースであり、両方の送受信、そのような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誤差を維持するのに十分なものでなければなりません。ミリオン（ppm）精度当たり1部で十分であろう。
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.
測定点（S）：セッション設定間隔を参照してください。
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誤差を維持するのに十分なものでなければなりません。 1ppmの精度で十分であろう。
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.
測定点（S）：セッション設定間隔を参照してください。
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誤差を維持するのに十分なものでなければなりません。 1ppmの精度で十分であろう。
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のSYN」のようなものであってもよいです。より複雑な場合には、それはのようなものかもしれない「すべての<非常に多くの>ミリ秒を観察したIPv6での初期のTCPのSYN、およびすべての<非常に多くの>ミリ秒を観察した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誤差を維持するのに十分なものでなければなりません。 1ppmの精度で十分であろう。
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、そしてフェルナンドGontで議論されました。ベンチマーク手法でワーキンググループ、アル・モートン、デヴィッド・ニューマン、サラ銀行、およびトーレ・アンダーソンは、コメントをしました。
[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月。
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with Dual-Stack Hosts", RFC 6555, April 2012.
[RFC6555]ウイング、D.とA. Yourtchenko、 "ハッピー眼球：デュアルスタックホストと成功"、RFC 6555、2012年4月。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191]ムガール人、J.とS.デアリング、 "パスMTUディスカバリ"、RFC 1191、1990年11月。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981]マッキャン、J.、デアリング、S.、およびJ.ムガール人、RFC 1981、1996年8月 "IPバージョン6のパスMTUディスカバリー"。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン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. Senie、 "ネットワーク入力フィルタリング：IP Source Address Spoofingを使うサービス攻撃の敗北拒否"、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]ギリガン、R.、トムソン、S.、バウンド、J.、マッキャン、J.、およびW.スティーブンス、 "IPv6の基本的なソケットインタフェース拡張"、RFC 3493、2003年2月。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007.
[RFC4821]マシス、M.とJ. Heffner、 "パケット化レイヤのパスMTUディスカバリ"、RFC 4821、2007年3月。
[RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, February 2009.
[RFC 5461]。、 "ソフトエラーへのTCPの反応" のフォント、RFC 5461、2009年2月。
Author's Address
著者のアドレス
Fred Baker Cisco Systems Santa Barbara, California 93117 USA
フレッドベイカーシスコシステムズサンタバーバラ、カリフォルニア93117 USA
EMail: fred@cisco.com
メールアドレス：fred@cisco.com