A One-way Packet Loss Metric for IPPM
RFC 2680
| Document | Type |
RFC - Proposed Standard
(September 1999; Errata)
Obsoleted by RFC 7680
Was draft-ietf-ippm-loss (ippm WG)
|
|
|---|---|---|---|
| Last updated | 2020-01-21 | ||
| Stream | IETF | ||
| Formats | plain text html pdf htmlized with errata bibtex | ||
| Stream | WG state | (None) | |
| Document shepherd | No shepherd assigned | ||
| IESG | IESG state | RFC 2680 (Proposed Standard) | |
| Consensus Boilerplate | Unknown | ||
| Telechat date | |||
| Responsible AD | (None) | ||
| Send notices to | (None) | ||
Network Working Group G. Almes
Request for Comments: 2680 S. Kalidindi
Category: Standards Track M. Zekauskas
Advanced Network & Services
September 1999
A One-way Packet Loss 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 one-way packet loss 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 One-way Delay ("A One-way Delay Metric for IPPM") [2];
the reader is assumed to be familiar with that document.
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 [5].
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-Loss, is
introduced to measure a single observation of packet transmission
or loss.
Almes, et al. Standards Track [Page 1]
RFC 2680 One Way Packet Loss Metric for IPPM September 1999
+ Using this singleton metric, a 'sample', called Type-P-One-way-
Loss-Poisson-Stream, is introduced to measure a sequence of
singleton transmissions and/or losses measured at times taken from
a Poisson process.
+ Using this sample, several 'statistics' of the sample are 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:
Understanding one-way packet loss of Type-P* packets 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
loss between hosts is large relative to some threshold value.
+ Excessive packet loss may make it difficult to support certain
real-time applications (where the precise threshold of "excessive"
depends on the application).
+ The larger the value of packet loss, the more difficult it is for
transport-layer protocols to sustain high bandwidths.
+ The sensitivity of real-time applications and of transport-layer
protocols to loss become especially important when very large
delay-bandwidth products must be supported.
The measurement of one-way loss instead of round-trip loss 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
different Internet service providers, and even radically different
types of networks (for example, research versus commodity
networks, or ATM versus packet-over-SONET).
Almes, et al. Standards Track [Page 2]
RFC 2680 One Way Packet Loss Metric for IPPM September 1999
+ 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.
Show full document text