A One-way Delay Metric for IPPM
RFC 2679
Document | Type |
RFC - Proposed Standard
(September 1999; Errata)
Obsoleted by RFC 7679
Was draft-ietf-ippm-delay (ippm WG)
|
|
---|---|---|---|
Authors | Sunil Kalidindi , Matthew Zekauskas , Guy Almes | ||
Last updated | 2013-03-02 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 2679 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
Network Working Group G. Almes Request for Comments: 2679 S. Kalidindi Category: Standards Track M. Zekauskas Advanced Network & Services September 1999 A One-way Delay Metric for IPPM 1. 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 traverse Almes, 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,Show full document text