Internet Engineering Task Force (IETF) F. Baker
Request for Comments: 6556 Cisco Systems
Category: Informational April 2012
ISSN: 2070-1721
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批准的所有文件都适用于任何级别的互联网标准；见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
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从该文档中提取的代码组件必须
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节中所述的简化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
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]规范指出了部署的仅限多前缀IPv6和双栈网络中的一个问题，并提出了一个更正。[RFC5461]同样关注TCP对所谓的“软错误”（ICMP主机和网络无法访问的消息）的响应，指出了一个问题和一组可能的解决方案。
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入口过滤[RFC2827]的上游提供商分配的多个前缀的纯IPv6网络中，需要通信的两台主机具有使用相同体系结构的地址这一事实并不意味着网络具有连接它们的可用路由，或者这些地址对所讨论的应用程序有用。此外，使用套接字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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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
此度量确定应用程序在至少存在一个IPv4和多个IPv6前缀以及各种网络行为的情况下与对等方建立会话所需的时间量。ISP报告说，具有多个地址（一个IPv4和一个IPv6地址、两个全局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).
企图有报道称，由于各种应用程序和操作系统的组合，会话设置时间很长，从几秒钟到半小时不等。在两个实体之间建立通信所需的时间应大致相同，无论选择的地址类型或特定网络中路由的可行性如何；用户希望这一次与他们当前的体验保持一致（否则，幸福感就会受到威胁）。
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 |
+--------+ | |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.
Alice是被测量的单位，运行该过程的计算机将与Bob建立有关应用程序的会话。DNS在图中表示为一个单独的系统，协议分析器也将监视Alice的流量。这并非绝对必要；如果一台计算机可以运行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 向Bob丢弃数据报的过滤器，导致ICMP“管理禁止”，
o a filter that silently drops datagrams to Bob,
o 一个过滤器，它会无声地将数据报发送给Bob，
o a null route or removing the route to one of Bob's prefixes, resulting in an ICMP "destination unreachable", and
o 空路由或删除到Bob前缀之一的路由，导致ICMP“无法到达目的地”，以及
o a middleware program that responds with a TCP RST.
o 用TCP RST响应的中间件程序。
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:db8:0:3:：/64上的MTU设置为地址系列（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节所述的网络。Alice和Bob各自有一组一个或多个IPv4地址和两个或多个IPv6地址。Bob的在DNS中，Alice可以在那里找到它们；爱丽丝和其他人的也可能在那里，但他们与测试无关。路由器1和2被配置为路由相关前缀。不同的测量试验修改了路由器1中的访问列表或空路由，这将阻止流量Alice->Bob使用Bob的每个地址。如果Bob总共有N个地址，我们至少运行N次测量，每次只允许其中一个地址享受端到端通信。如果DNS服务随机化地址的顺序，这可能不会导致需要建立到所有地址的连接的测试；在这种情况下，必须重复运行测试，直到至少在一个实例中看到每个相关地址的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.
目标是测量建立会话所需的时间量。这包括从Alice的初始DNS请求到一次或多次尝试建立会话到正在建立会话的时间，如LAN跟踪中所示。衡量这一点的最简单方法是在Alice的连接点上放置一个流量分析器，并捕获Alice交换的消息。
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------->|<***********
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行）到TCP三方握手（第12行）的第一次完成（上面简称为“3wHS”）。
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---|<---------
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）中，从DNS请求（第1行）到一个或多个UDP请求（第6-10行），直到看到UDP响应（第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请求到会话被视为已建立的时间间隔的持续时间。我们感兴趣的是最短和最长的持续时间（最有可能是发送一个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.
应在Alice的连接点观察发送和接收消息的所有测量事件，并在接收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查询开始（在Alice的附件中观察到）到成功建立传输连接结束的时间（如图2的第12行和图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上配置）的每个可能组合运行一次。
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 analyzer跟踪中，按照第2.2节所述记录初始DNS请求的时间和会话打开的确认时间。如果会话未成功打开（可能是由于Alice中止了尝试），则会话设置间隔被认为是无限的。
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.
测量点：测量点位于Alice的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毫秒的误差。百万分之一（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毫秒的误差。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毫秒的误差。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 SYN”；在更复杂的情况下，它可能类似于“IPv6中的初始TCP SYN每<这么多>毫秒观察一次，而使用IPv4的其他TCP SYN每<这么多>毫秒观察一次，但这两个序列是独立的。”如果观察到，它还可能对重传模式进行评论。
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.
测量点：测量点位于Alice的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 ppm precision would suffice.
计时：测量程序或外部分析仪必须运行足够长的时间，以捕获第2.2节所述的整个消息流。测量精度必须足以在60秒的间隔内保持不超过0.1毫秒的误差。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.
这张便条与丹·温、安德鲁·尤琴科和费尔南多·冈特进行了讨论。在基准方法工作组中，Al Morton、David Newman、Sarah Banks和Tore Anderson发表了评论。
[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.和A.Yourtchenko，“快乐眼球：双堆栈主机的成功”，RFC 6555，2012年4月。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791]Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191]Mogul，J.和S.Deering，“MTU发现路径”，RFC1191，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的路径MTU发现”，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，“互联网协议，第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]Ferguson，P.和D.Senie，“网络入口过滤：击败利用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，“打包层路径MTU发现”，RFC 48212007年3月。
[RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, February 2009.
[RFC5461]Gont，F.，“TCP对软错误的反应”，RFC 54612009年2月。
Author's Address
作者地址
Fred Baker Cisco Systems Santa Barbara, California 93117 USA
美国加利福尼亚州圣巴巴拉市弗雷德·贝克思科系统公司，邮编：93117
EMail: fred@cisco.com
EMail: fred@cisco.com