Defining Network Capacity
RFC 5136
|
Document |
Type |
|
RFC - Informational
(February 2008; No errata)
|
|
Authors |
|
Joseph Ishac
,
Phil Chimento
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
html
pdf
htmlized
bibtex
|
|
Reviews |
|
|
Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
IESG |
IESG state |
|
RFC 5136 (Informational)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
Lars Eggert
|
|
Send notices to |
|
(None)
|
Network Working Group P. Chimento
Request for Comments: 5136 JHU Applied Physics Lab
Category: Informational J. Ishac
NASA Glenn Research Center
February 2008
Defining Network Capacity
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.
Abstract
Measuring capacity is a task that sounds simple, but in reality can
be quite complex. In addition, the lack of a unified nomenclature on
this subject makes it increasingly difficult to properly build, test,
and use techniques and tools built around these constructs. This
document provides definitions for the terms 'Capacity' and 'Available
Capacity' related to IP traffic traveling between a source and
destination in an IP network. By doing so, we hope to provide a
common framework for the discussion and analysis of a diverse set of
current and future estimation techniques.
Chimento & Ishac Informational [Page 1]
RFC 5136 Network Capacity February 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Links and Paths . . . . . . . . . . . . . . . . . . . . . 4
2.2. Definition: Nominal Physical Link Capacity . . . . . . . . 4
2.3. Capacity at the IP Layer . . . . . . . . . . . . . . . . . 5
2.3.1. Definition: IP-layer Bits . . . . . . . . . . . . . . 5
2.3.1.1. Standard or Correctly Formed Packets . . . . . . . 5
2.3.1.2. Type P Packets . . . . . . . . . . . . . . . . . . 6
2.3.2. Definition: IP-type-P Link Capacity . . . . . . . . . 7
2.3.3. Definition: IP-type-P Path Capacity . . . . . . . . . 7
2.3.4. Definition: IP-type-P Link Usage . . . . . . . . . . . 7
2.3.5. Definition: IP-type-P Link Utilization . . . . . . . . 8
2.3.6. Definition: IP-type-P Available Link Capacity . . . . 8
2.3.7. Definition: IP-type-P Available Path Capacity . . . . 8
3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Time and Sampling . . . . . . . . . . . . . . . . . . . . 9
3.2. Hardware Duplicates . . . . . . . . . . . . . . . . . . . 9
3.3. Other Potential Factors . . . . . . . . . . . . . . . . . 9
3.4. Common Terminology in Literature . . . . . . . . . . . . . 10
3.5. Comparison to Bulk Transfer Capacity (BTC) . . . . . . . . 10
4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . . 12
Chimento & Ishac Informational [Page 2]
RFC 5136 Network Capacity February 2008
1. Introduction
Measuring the capacity of a link or network path is a task that
sounds simple, but in reality can be quite complex. Any physical
medium requires that information be encoded and, depending on the
medium, there are various schemes to convert information into a
sequence of signals that are transmitted physically from one location
to another.
While on some media, the maximum frequency of these signals can be
thought of as "capacity", on other media, the signal transmission
frequency and the information capacity of the medium (channel) may be
quite different. For example, a satellite channel may have a carrier
frequency of a few gigahertz, but an information-carrying capacity of
only a few hundred kilobits per second. Often similar or identical
terms are used to refer to these different applications of capacity,
adding to the ambiguity and confusion, and the lack of a unified
nomenclature makes it difficult to properly build, test, and use
various techniques and tools.
We are interested in information-carrying capacity, but even this is
not straightforward. Each of the layers, depending on the medium,
adds overhead to the task of carrying information. The wired
Ethernet uses Manchester coding or 4/5 coding, which cuts down
considerably on the "theoretical" capacity. Similarly, RF (radio
frequency) communications will often add redundancy to the coding
scheme to implement forward error correction because the physical
Show full document text