📄 rfc2679.txt
字号:
Network Working Group G. AlmesRequest for Comments: 2679 S. KalidindiCategory: Standards Track M. Zekauskas Advanced Network & Services September 1999 A One-way Delay Metric for IPPM1. Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved.2. Introduction This memo defines a metric for one-way delay of packets across Internet paths. It builds on notions introduced and discussed in the IPPM Framework document, RFC 2330 [1]; the reader is assumed to be familiar with that document. This memo is intended to be parallel in structure to a companion document for Packet Loss ("A One-way Packet Loss Metric for IPPM") [2]. 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 RFC 2119 [6]. Although RFC 2119 was written with protocols in mind, the key words are used in this document for similar reasons. They are used to ensure the results of measurements from two different implementations are comparable, and to note instances when an implementation could perturb the network. The structure of the memo is as follows: + A 'singleton' analytic metric, called Type-P-One-way-Delay, will be introduced to measure a single observation of one-way delay.Almes, et al. Standards Track [Page 1] RFC 2679 A One-way Delay Metric for IPPM September 1999 + Using this singleton metric, a 'sample', called Type-P-One-way- Delay-Poisson-Stream, will be introduced to measure a sequence of singleton delays measured at times taken from a Poisson process. + Using this sample, several 'statistics' of the sample will be defined and discussed. This progression from singleton to sample to statistics, with clear separation among them, is important. Whenever a technical term from the IPPM Framework document is first used in this memo, it will be tagged with a trailing asterisk. For example, "term*" indicates that "term" is defined in the Framework.2.1. Motivation: One-way delay of a Type-P* packet from a source host* to a destination host is useful for several reasons: + Some applications do not perform well (or at all) if end-to-end delay between hosts is large relative to some threshold value. + Erratic variation in delay makes it difficult (or impossible) to support many real-time applications. + The larger the value of delay, the more difficult it is for transport-layer protocols to sustain high bandwidths. + The minimum value of this metric provides an indication of the delay due only to propagation and transmission delay. + The minimum value of this metric provides an indication of the delay that will likely be experienced when the path* traversed is lightly loaded. + Values of this metric above the minimum provide an indication of the congestion present in the path. The measurement of one-way delay instead of round-trip delay is motivated by the following factors: + In today's Internet, the path from a source to a destination may be different than the path from the destination back to the source ("asymmetric paths"), such that different sequences of routers are used for the forward and reverse paths. Therefore round-trip measurements actually measure the performance of two distinct paths together. Measuring each path independently highlights the performance difference between the two paths which may traverseAlmes, et al. Standards Track [Page 2] RFC 2679 A One-way Delay Metric for IPPM September 1999 different Internet service providers, and even radically different types of networks (for example, research versus commodity networks, or ATM versus packet-over-SONET). + Even when the two paths are symmetric, they may have radically different performance characteristics due to asymmetric queueing. + Performance of an application may depend mostly on the performance in one direction. For example, a file transfer using TCP may depend more on the performance in the direction that data flows, rather than the direction in which acknowledgements travel. + In quality-of-service (QoS) enabled networks, provisioning in one direction may be radically different than provisioning in the reverse direction, and thus the QoS guarantees differ. Measuring the paths independently allows the verification of both guarantees. It is outside the scope of this document to say precisely how delay metrics would be applied to specific problems.2.2. General Issues Regarding Time {Comment: the terminology below differs from that defined by ITU-T documents (e.g., G.810, "Definitions and terminology for synchronization networks" and I.356, "B-ISDN ATM layer cell transfer performance"), but is consistent with the IPPM Framework document. In general, these differences derive from the different backgrounds; the ITU-T documents historically have a telephony origin, while the authors of this document (and the Framework) have a computer systems background. Although the terms defined below have no direct equivalent in the ITU-T definitions, after our definitions we will provide a rough mapping. However, note one potential confusion: our definition of "clock" is the computer operating systems definition denoting a time-of-day clock, while the ITU-T definition of clock denotes a frequency reference.} Whenever a time (i.e., a moment in history) is mentioned here, it is understood to be measured in seconds (and fractions) relative to UTC. As described more fully in the Framework document, there are four distinct, but related notions of clock uncertainty:Almes, et al. Standards Track [Page 3] RFC 2679 A One-way Delay Metric for IPPM September 1999 synchronization* measures the extent to which two clocks agree on what time it is. For example, the clock on one host might be 5.4 msec ahead of the clock on a second host. {Comment: A rough ITU-T equivalent is "time error".} accuracy* measures the extent to which a given clock agrees with UTC. For example, the clock on a host might be 27.1 msec behind UTC. {Comment: A rough ITU-T equivalent is "time error from UTC".} resolution* measures the precision of a given clock. For example, the clock on an old Unix host might tick only once every 10 msec, and thus have a resolution of only 10 msec. {Comment: A very rough ITU-T equivalent is "sampling period".} skew* measures the change of accuracy, or of synchronization, with time. For example, the clock on a given host might gain 1.3 msec per hour and thus be 27.1 msec behind UTC at one time and only 25.8 msec an hour later. In this case, we say that the clock of the given host has a skew of 1.3 msec per hour relative to UTC, which threatens accuracy. We might also speak of the skew of one clock relative to another clock, which threatens synchronization. {Comment: A rough ITU-T equivalent is "time drift".}3. A Singleton Definition for One-way Delay3.1. Metric Name: Type-P-One-way-Delay3.2. Metric Parameters: + Src, the IP address of a host + Dst, the IP address of a host + T, a timeAlmes, et al. Standards Track [Page 4] RFC 2679 A One-way Delay Metric for IPPM September 19993.3. Metric Units: The value of a Type-P-One-way-Delay is either a real number, or an undefined (informally, infinite) number of seconds.3.4. Definition: For a real number dT, >>the *Type-P-One-way-Delay* from Src to Dst at T is dT<< means that Src sent the first bit of a Type-P packet to Dst at wire-time* T and that Dst received the last bit of that packet at wire-time T+dT. >>The *Type-P-One-way-Delay* from Src to Dst at T is undefined (informally, infinite)<< means that Src sent the first bit of a Type-P packet to Dst at wire-time T and that Dst did not receive that packet. Suggestions for what to report along with metric values appear in Section 3.8 after a discussion of the metric, methodologies for measuring the metric, and error analysis.3.5. Discussion: Type-P-One-way-Delay is a relatively simple analytic metric, and one that we believe will afford effective methods of measurement. The following issues are likely to come up in practice: + Real delay values will be positive. Therefore, it does not make sense to report a negative value as a real delay. However, an individual zero or negative delay value might be useful as part of a stream when trying to discover a distribution of a stream of delay values. + Since delay values will often be as low as the 100 usec to 10 msec range, it will be important for Src and Dst to synchronize very closely. GPS systems afford one way to achieve synchronization to within several 10s of usec. Ordinary application of NTP may allow synchronization to within several msec, but this depends on the stability and symmetry of delay properties among those NTP agents used, and this delay is what we are trying to measure. A combination of some GPS-based NTP servers and a conservatively designed and deployed set of other NTP servers should yield good results, but this is yet to be tested. + A given methodology will have to include a way to determine whether a delay value is infinite or whether it is merely very large (and the packet is yet to arrive at Dst). As noted byAlmes, et al. Standards Track [Page 5] RFC 2679 A One-way Delay Metric for IPPM September 1999 Mahdavi and Paxson [4], simple upper bounds (such as the 255 seconds theoretical upper bound on the lifetimes of IP packets [5]) could be used, but good engineering, including an understanding of packet lifetimes, will be needed in practice. {Comment: Note that, for many applications of these metrics, the harm in treating a large delay as infinite might be zero or very small. A TCP data packet, for example, that arrives only after several multiples of the RTT may as well have been lost.} + If the packet is duplicated along the path (or paths) so that multiple non-corrupt copies arrive at the destination, then the packet is counted as received, and the first copy to arrive determines the packet's one-way delay. + If the packet is fragmented and if, for whatever reason, reassembly does not occur, then the packet will be deemed lost.3.6. Methodologies: As with other Type-P-* metrics, the detailed methodology will depend on the Type-P (e.g., protocol number, UDP/TCP port number, size, precedence). Generally, for a given Type-P, the methodology would proceed as follows: + Arrange that Src and Dst are synchronized; that is, that they have clocks that are very closely synchronized with each other and each fairly close to the actual time. + At the Src host, select Src and Dst IP addresses, and form a test packet of Type-P with these addresses. Any 'padding' portion of the packet needed only to make the test packet a given size should be filled with randomized bits to avoid a situation in which the measured delay is lower than it would otherwise be due to compression techniques along the path. + At the Dst host, arrange to receive the packet. + At the Src host, place a timestamp in the prepared Type-P packet, and send it towards Dst. + If the packet arrives within a reasonable period of time, take a timestamp as soon as possible upon the receipt of the packet. By subtracting the two timestamps, an estimate of one-way delay can be computed. Error analysis of a given implementation of the method must take into account the closeness of synchronization between Src and Dst. If the delay between Src's timestamp and theAlmes, et al. Standards Track [Page 6] RFC 2679 A One-way Delay Metric for IPPM September 1999 actual sending of the packet is known, then the estimate could be adjusted by subtracting this amount; uncertainty in this value must be taken into account in error analysis. Similarly, if the delay between the actual receipt of the packet and Dst's timestamp is known, then the estimate could be adjusted by subtracting this amount; uncertainty in this value must be taken into account in error analysis. See the next section, "Errors and Uncertainties", for a more detailed discussion. + If the packet fails to arrive within a reasonable period of time, the one-way delay is taken to be undefined (informally, infinite). Note that the threshold of 'reasonable' is a parameter of the methodology. Issues such as the packet format, the means by which Dst knows when to expect the test packet, and the means by which Src and Dst are synchronized are outside the scope of this document. {Comment: We plan to document elsewhere our own work in describing such more detailed implementation techniques and we encourage others to as well.}3.7. Errors and Uncertainties: The description of any specific measurement method should include an accounting and analysis of various sources of error or uncertainty. The Framework document provides general guidance on this point, but we note here the following specifics related to delay metrics: + Errors or uncertainties due to uncertainties in the clocks of the Src and Dst hosts. + Errors or uncertainties due to the difference between 'wire time' and 'host time'.⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -