RFC 3148 (rfc3148) - Page 1 of 16

A Framework for Defining Empirical Bulk Transfer Capacity Metrics

Alternative Format: Original Text Document
Next >
Network Working Group                                          M. Mathis
Request for Comments: 3148              Pittsburgh Supercomputing Center
Category: Informational                                        M. Allman
                                                          BBN/NASA Glenn
                                                               July 2001


   A Framework for Defining Empirical Bulk Transfer Capacity Metrics

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract

   This document defines a framework for standardizing multiple BTC
   (Bulk Transport Capacity) metrics that parallel the permitted
   transport diversity.

1   Introduction

   Bulk Transport Capacity (BTC) is a measure of a network's ability to
   transfer significant quantities of data with a single congestion-
   aware transport connection (e.g., TCP).  The intuitive definition of
   BTC is the expected long term average data rate (bits per second) of
   a single ideal TCP implementation over the path in question.
   However, there are many congestion control algorithms (and hence
   transport implementations) permitted by IETF standards.  This
   diversity in transport algorithms creates a difficulty for
   standardizing BTC metrics because the allowed diversity is sufficient
   to lead to situations where different implementations will yield
   non-comparable measures -- and potentially fail the formal tests for
   being a metric.

   Two approaches are used.  First, each BTC metric must be much more
   tightly specified than the typical IETF protocol.  Second, each BTC
   methodology is expected to collect some ancillary metrics which are
   potentially useful to support analytical models of BTC.

   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].  Although



Mathis, et al.               Informational
Next >