datatracker.ietf.org
Sign in
Version 5.6.4.p1, 2014-10-20
Report a bug

A One-way Delay Metric for IPPM
RFC 2679

Document type: RFC - Proposed Standard (September 1999; Errata)
Document stream: IETF
Last updated: 2013-03-02
Other versions: plain text, pdf, html

IETF State: (None)
Document shepherd: No shepherd assigned

IESG State: RFC 2679 (Proposed Standard)
Responsible AD: (None)
Send notices to: No addresses provided

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).

[include full document text]