A Round-trip Delay Metric for IPPM
RFC 2681
|
| Document |
Type |
|
RFC - Proposed Standard
(September 1999; Errata)
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 2681 (Proposed Standard)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
Network Working Group G. Almes
Request for Comments: 2681 S. Kalidindi
Category: Standards Track M. Zekauskas
Advanced Network & Services
September 1999
A Round-trip Delay Metric for IPPM
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.
1. Introduction
This memo defines a metric for round-trip delay of packets across
Internet paths. It builds on notions introduced and discussed in the
IPPM Framework document, RFC 2330 [1], and follows closely the
corresponding metric for One-way Delay ("A One-way Delay Metric for
IPPM") [2]; the reader is assumed to be familiar with those
documents.
The memo was largely written by copying material from the One-way
Delay metric. The intention is that, where the two metrics are
similar, they will be described with similar or identical text, and
that where the two metrics differ, new or modified text will be used.
This memo is intended to be parallel in structure to a future
companion document for Packet Loss.
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.
Almes, et al. Standards Track [Page 1]
RFC 2681 Round-trip for Delay Metric for IPPM September 1999
The structure of the memo is as follows:
+ A 'singleton' analytic metric, called Type-P-Round-trip-Delay,
will be introduced to measure a single observation of round-trip
delay.
+ Using this singleton metric, a 'sample', called Type-P-Round-trip-
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.
1.1. Motivation
Round-trip 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 interactive 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.
Almes, et al. Standards Track [Page 2]
RFC 2681 Round-trip for Delay Metric for IPPM September 1999
The measurement of round-trip delay instead of one-way delay has
several weaknesses, summarized here:
+ The Internet path from a source to a destination may differ from
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.
+ 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.
+ In quality-of-service (QoS) enabled networks, provisioning in one
Show full document text