RFC 2681 (rfc2681) - Page 1 of 20

A Round-trip Delay Metric for IPPM

Alternative Format: Original Text Document
Next >
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
Next >