Throughput Estimation for MPLS based Transport Networks
draft-xiao-mpls-tp-throughput-estimation-01

Abstract

An important Operation, Administration and Maintenance requirement of the MPLS Transport Profile (MPLS-TP) is the ability to estimate the throughput (i.e. bandwidth) for an MPLS-TP connection which could be an MPLS-TP PW, LSP or Section. This document specifies OAM packets and protocol mechanisms to facilitate the efficient and precise measurement of throughput.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

This Internet-Draft will expire on April 18, 2011.

Copyright Notice

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1.  Introduction
    1.1.  Conventions
    1.2.  Abbreviations
2.  Overview
    2.1.  Two-way Throughput Measurement
    2.2.  One-way Throughput Measurement
    2.3.  Unidirectional Connections
3.  Packet Format
    3.1.  Throughput Measurement Indication Packet Format
    3.2.  Throughput Measurement Test Packet Format
4.  Throughput Measurement Procedures
    4.1.  Transmitting a Throughput Measurement Start Request
    4.2.  Receiving a Throughput Measurement Start Request
    4.3.  Transmitting a Throughput Measurement Start Reply
    4.4.  Receiving a Throughput Measurement Start Reply
    4.5.  Sending and Receiving Test Traffic
    4.6.  Transmitting a Throughput Measurement Stop Request
    4.7.  Receiving a Throughput Measurement Stop Request
    4.8.  Transmitting a Throughput Measurement Stop Reply
    4.9.  Receiving a Throughput Measurement Stop Reply
    4.10.  Consequent Actions and Searching Algorithm
5.  Throughput Measurement Time
6.  Open Issue
7.  IANA Considerations
8.  Security Considerations
9.  Acknowledgements
10.  References
    10.1.  Normative References
    10.2.  Informative References
§  Authors' Addresses

1.  Introduction

As defined in [RFC5860] (Vigoureux, M., Ward, D., and M. Betts, “Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks,” May 2010.), the MPLS-TP OAM toolset MUST provide a function to enable conducting diagnostic tests on a PW, LSP or Section, this function SHOULD be performed on-demand and one example of such diagnostic test consists in estimating the bandwidth of e.g., an LSP.

To make this requirement clearer and provide more details, this sub-function of diagnostic tests is specified as "throughput estimation" in [I‑D.ietf‑mpls‑tp‑oam‑framework] (Allan, D., Busi, I., Niven-Jenkins, B., Fulignoli, A., Hernandez-Valencia, E., Levrau, L., Sestito, V., Sprecher, N., Helvoort, H., Vigoureux, M., Weingarten, Y., and R. Winter, “Operations, Administration and Maintenance Framework for MPLS- based Transport Networks,” October 2010.), throughput estimation is an on-demand out-of-service function, that allows verifying the bandwidth/throughput of an MPLS-TP transport path (LSP or PW) before it is put in-service. Throughput estimation is performed between MEPs and can be performed in one-way or two-way mode.

This document specifies the OAM packets and procedures for both one-way and two-way throughput estimation/measurement.

1.1.  Conventions

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 [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

1.2.  Abbreviations

CRC: Cyclic Redundancy Check

G-ACh: Generic Associated Channel

DUT: Device Under Test

LSP: Label Switched Path

MEG: Maintenance Entity Group

MEP: Maintenance Entity Group End Point

MPLS-TP: MPLS Transport Profile

NMS: Network Management System

OAM: Operations, Administration and Maintenance

PHB: Per-hop Behavior

PRBS: Pseudo-Random Bit Sequence

PW: PseudoWire

TLV: Type Length Value

2.  Overview

In [RFC1242] (Bradner, S., “Benchmarking terminology for network interconnection devices,” July 1991.), the throughput is specified as a performance metric for network interconnection device, and it's defined by "the maximum rate at which none of the offered frames are dropped by the device". In MPLS-TP context the concept of throughput is not just for a particular device, but extended to apply to an MPLS-TP connection which could be a PW, LSP or Section.

In [RFC2544] (Bradner, S. and J. McQuaid, “Benchmarking Methodology for Network Interconnect Devices,” March 1999.), corresponding to [RFC1242] (Bradner, S., “Benchmarking terminology for network interconnection devices,” July 1991.), the throughput measurement procedures are specified as "send a specific number of frames at a specific rate through the DUT and then count the frames that are transmitted by the DUT. If the count of offered frames is equal to the count of received frames, the fewer frames are received than were transmitted, the rate of the offered stream is reduced and the test is rerun. The throughput is the fastest rate at which the count of test frames transmitted by the DUT is equal to the number of test frames sent to it by the test equipment". But in current practical throughput measurement scenario, usually the throughput is measured by test equipment using the more efficient and precise binary search algorithm.

It should also be noted that for different test packet size, or test packet pattern, or test packet PHB, or expected measurement resolution, or even sending duration of test traffic, different result of throughput measurement may be obtained, so all these parameters need to be configurable for throughput measurement.

2.1.  Two-way Throughput Measurement

For a bidirectional MPLS-TP connection, two-way throughput measurement needs to be supported. Two-way throughput should include both the throughput for the forward direction of the connection and the throughput for the reverse direction of the connection. In order to simplify the implementation and facilitate the results collection, all computational overhead and procedures control will be taken by the initiator MEP of throughput measurement, and the peer MEP will act just as a responder. Also note that both the initiator MEP and the peer MEP need to send test traffic for two-way throughput measurement.

It is worth noting that there is another optional definition of two-way throughput estimation, in which only the initiator MEP needs to send test traffic and the peer MEP will loop back all received test packets. But note that in this case only the minimum of available throughput of the two directions can be achieved, so this optional definition of two-way throughput estimation is not recommended in this draft.

2.2.  One-way Throughput Measurement

For a bidirectional MPLS-TP connection, one-way throughput measurement also needs to be supported. One-way throughput only indicates the throughput for the forward direction of the connection. Similar to two-way throughput measurement, the initiator MEP controls the whole process of one-way throughput measurement and the peer MEP will act just as a responder. Also note that only the initiator MEP needs to send test traffic for one-way throughput measurement.

2.3.  Unidirectional Connections

For a unidirectional MPLS-TP connection (such as a unidirectional LSP), only one-way throughput measurement needs to be supported. If it's a unidirectional connection with return path, the procedures of one-way throughput measurement for bidirectional connection still apply. Else if it's a unidirectional connection without return path, the procedures of one-way throughput measurement are not as automatic as that for bidirectional connection, and manual provision of test parameters is needed for every run of sending test traffic. Besides, in this case the peer MEP instead of the initiator MEP will act as calculator for the packet loss of every run.

3.  Packet Format

For throughput measurement the specific packets sent by the MEP can be divided into indication packets and test packets. The throughput measurement indication packets flow over the Generic Associated Channel Channel (G-ACh) [RFC5586] (Bocci, M., Vigoureux, M., and S. Bryant, “MPLS Generic Associated Channel,” June 2009.) of an MPLS-TP connection and perform signaling between the initiator MEP and the peer MEP, while the throughput measurement test packets compose the test traffic which intends to emulate the real user traffic.

3.1.  Throughput Measurement Indication Packet Format

The format of a throughput measurement indication packet is shown below.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 1|Version|   Reserved    |  0xHH (Thput Meas Indication) |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               ~
     ~            Throughput Measurement Indication Message          ~
     ~                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Version and Reserved field are always set to 0.

The Thput Meas Indication Channel Type is 0xHH (to be assigned by IANA).

The format of a throughput measurement indication message is shown below.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Version| Flags |   Run Count   |  Control Code | Total TLV Len |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             TLVs                              |
     ~                                                               ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Version

   The Version Number is currently set to 0.

Flags

Each bit indicates a message control flag. Three flags are defined and listed from left to right as follow:

     +-+-+-+-+
     |W|S|R|E|
     +-+-+-+-+

W-flag: This Flag represents the operational mode which could be One-way mode or Two-way mode. Set to 0 for a One-way throughput measurement; Set to 1 for a Two-way throughput measurement.

S-flag: This Flag represents the message type which could be Start type or Stop type. Set to 0 for a Start message; Set to 1 for a Stop message.

R-flag: This Flag represents the message direction which could be Forward direction (i.e. Request) or Reverse direction (i.e. Reply). Set to 0 for a Request message; Set to 1 for a Reply message.

E bit (the fourth bit): Reserved for future use and set to 0.

Run Count

The Run Count is set to the number of all run times in one throughput measurement process and it starts from 1.

Control Code

According to the value of R-flag, the Control Code is set as follow.

For a Request:

0x0: Request (in-band reply requested). Indicates that this request has been sent over a bidirectional connection and the reply is expected over the same connection.

0x1: Request (out-of-band reply requested). Indicates that the reply is expected over an out-of-band path.

0x2: Request (no reply requested). Indicates that no reply is expected.

For a Reply:

0x0: Success. Indicates that the operation succeeded.

0x1: Error. Indicates that the operation failed.

Total TLV Length

The total TLV length is the total of all included TLVs.

TLVs

According to the values of W-flag, S-flag and R-flag, the TLVs are defined as follow.

For Start Request/Reply message in One-way throughput measurement:

No TLVs are defined at this time.

For Start Request/Reply message in Two-way throughput measurement:

One TLV is defined as follow.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Type = 0           |         Length = 10           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Sending Rate                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Sending Duration       |         Packet Size           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Packet Pattern| PHB | Reserved|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

All the values in this TLV are test parameters for the peer MEP to send test traffic.

Sending Rate

The Sending Rate in Mbps is set to the provisioned initial sending rate of test traffic for the first run, and set to the calculated sending rate of test traffic for the rerun.

Sending Duration

The Sending Duration in seconds is set to the provisioned sending interval of test traffic for every run.

Packet Size

The Packet Size in octets is set to the provisioned throughput measurement test packet size.

Packet Pattern

The Packet Pattern is set to the provisioned throughput measurement test packet pattern. According to [ITU‑T Y.1731] (International Telecommunications Union - Telecommunication Standardization, “OAM functions and mechanisms for Ethernet based networks,” February 2008.), four pattern types of throughput measurement test packets pattern types are defined as below:

0x00: Null (all-zeros) signal without CRC-32

0x01: Null (all-zeros) signal with CRC-32

0x02: PRBS (2^31-1) without CRC-32

0x03: PRBS (2^31-1) with CRC-32

0x04~0xFF: Reserved for future standardization

PHB

The PHB is set to the provisioned throughput measurement test packet PHB.

Reserved

Reserved bits for future use and always set to 0.

For Stop Request/Reply message in One-way/Two-way throughput measurement:

One TLV is defined as follow.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Type = 1           |         Length = 16           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Tx Counter                          |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Rx Counter                          |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Tx Counter

Tx Counter is set to the number of throughput measurement test packets sent by the local MEP (i.e. the MEP sending this indication message) in this run.

Rx Counter

Rx Counter is set to the number of throughput measurement test packets received by the local MEP (i.e. the MEP sending this indication message) in this run.

3.2.  Throughput Measurement Test Packet Format

In order to simplify the implementation of MPLS-TP OAM functions, the format of a throughput measurement test packet should be aligned with the format of a data plane loopback test packet, which is specified in section 5 of [I‑D.ietf‑mpls‑tp‑li‑lb] (Boutros, S., Sivabalan, S., Swallow, G., Bryant, S., and C. Pignataro, “MPLS Transport Profile Lock Instruct and Loopback Functions,” September 2010.). As indicated in section 3.1, four pattern types of throughput measurement test packets can be constructed based on Padding field and optional CRC-32 field.

4.  Throughput Measurement Procedures

As specified in [I‑D.ietf‑mpls‑tp‑oam‑framework] (Allan, D., Busi, I., Niven-Jenkins, B., Fulignoli, A., Hernandez-Valencia, E., Levrau, L., Sestito, V., Sprecher, N., Helvoort, H., Vigoureux, M., Weingarten, Y., and R. Winter, “Operations, Administration and Maintenance Framework for MPLS- based Transport Networks,” October 2010.), before throughput measurement is initiated, the diagnosed MEG should be put into a Lock status, and an MEG can be put into a Lock status either via NMS action or using the Lock Instruct OAM tool which is specified in [I‑D.ietf‑mpls‑tp‑li‑lb] (Boutros, S., Sivabalan, S., Swallow, G., Bryant, S., and C. Pignataro, “MPLS Transport Profile Lock Instruct and Loopback Functions,” September 2010.). In addition, the test parameters for sending test traffic need to be provisioned at the initiator MEP before initiating a throughput measurement, and they include initial sending rate, sending duration for every run, test packet size, test packet Pattern, test packet PHB and also the expected measurement resolution. Also note that no any provision is needed at the peer MEP.

4.1.  Transmitting a Throughput Measurement Start Request

After initiating a throughput measurement operation, the initiator MEP will at first transmit a throughput measurement Start Request to the peer MEP. Also note that for every rerun of sending test traffic, the initiator MEP must transmit this message as beginning.

For one-way throughput measurement, this message is intended to inform the peer MEP about the start of test traffic sending and trigger the peer MEP to start counting test packets. Specifically if one-way throughput measurement is performed on a unidirectional MPLS-TP connection without return path, the initiator MEP also should start sending test traffic a while (such as 1 second) after transmitting the Start Request. For two-way throughput measurement, except for the same intention as one-way throughput measurement, this message is also intended to convey necessary test parameters to the peer MEP and trigger the test traffic sending at the peer MEP, and note that for rerun only Run Count and Sending Rate in the message need to be changed while other parameters retain initial values. Furthermore, for both one-way and two-way measurement, the initiator MEP should start counting test packets as soon as it transmits this message.

Specifically if the connection is unidirectional, then the Control Code in the message must not be set to 0x0 (in-band reply requested), moreover if no return path exists the Control Code in the message must be set to 0x2 (no reply requested).

4.2.  Receiving a Throughput Measurement Start Request

Upon the reception of a throughput measurement Start Request, the peer MEP must inspect this message at first, if no unexpected field or value is found then the peer MEP should start counting test packets. In addition, if the received W-flag indicates that this is a two-way throughput measurement, then the peer MEP also should start sending test traffic.

Specifically if the received W-flag indicates that this is a one-way throughput measurement, and the received Control Code is set to 0x2 (no reply requested) which means the connection is unidirectional without return path, then the peer MEP won't transmit Start Reply.

4.3.  Transmitting a Throughput Measurement Start Reply

When the Control Code in a received Start Request is set to 0x0 (in-band reply requested) or 0x1 (out-of-band reply requested), the peer MEP must transmit a throughput measurement Start Reply to the initiator MEP. The Control Code in Start Reply Message should be set to 0x0 to reflect the successful operation at the peer MEP, or on the contrary set to 0x1 to reflect the failed operation at the peer MEP. Except the R-flag and Control Code field, other fields of Start Reply Message will be copied from the received Start Request Message.

4.4.  Receiving a Throughput Measurement Start Reply

Upon the reception of a throughput measurement Start Reply, the initiator MEP must inspect this message at first, if no unexpected field or value is found, and the received Control Code indicates successful operation at the peer MEP, then the initiator MEP should start sending test traffic. If there is no any throughput measurement Start Reply received after a while (such as 1 second), then specific error should be returned at the initiator MEP and no test traffic will be sent from the initiator MEP.

4.5.  Sending and Receiving Test Traffic

From above procedures it can be seen that for two-way throughput measurement the pair of MEPs will send test traffic asynchronously, and the peer MEP will start/stop sending test traffic some earlier than the initiator MEP, but the asynchronism has no side-effect on the measurement result because both MEPs shall start counting test packets before they receive any test traffic.

Also note that when the initiator MEP sends test traffic the test parameters are all derived from the provisioned test parameters for the first run, and for rerun only the sending rate is changed and derived from the local calculation. When the peer MEP sends test traffic, the test parameters are all derived from the received Start Request Message.

4.6.  Transmitting a Throughput Measurement Stop Request

For every run, after the initiator MEP finished sending test traffic, it will transmit a throughput measurement Stop Request to the peer MEP. This message is intended to inform the peer MEP about the stop of test traffic sending, and also trigger the peer MEP to stop counting test packets and feed back the counters.

Specifically if the connection is unidirectional, then the Control Code in the message must not be set to 0x0 (in-band reply requested), moreover if no return path exists the Control Code in the message must be set to 0x2 (no reply requested).

4.7.  Receiving a Throughput Measurement Stop Request

Upon the reception of a throughput measurement Stop Request, the peer MEP must inspect this message at first, if no unexpected field or value is found then the peer MEP should stop counting test packets.

Specifically if the received W-flag indicates that this is a one-way throughput measurement, and the received Control Code is set to 0x2 (no reply requested) which means the connection is unidirectional without return path, then the peer MEP won't transmit Stop Reply and it will use the received Tx Counter to calculate test packet loss directly.

4.8.  Transmitting a Throughput Measurement Stop Reply

When the Control Code in a received Stop Request is set to 0x0 (in-band reply requested) or 0x1 (out-of-band reply requested), the peer MEP must transmit a throughput measurement Stop Reply to the initiator MEP. The Control Code in Stop Reply Message should be set to 0x0 to reflect the successful operation at the peer MEP, or on the contrary set to 0x1 to reflect the failed operation at the peer MEP. Furthermore, the Stop Reply is transmitted also to confirm that the peer MEP has stopped sending test traffic for this run. The Tx Counter and Rx Counter are set to the test packet counting values at the peer MEP.

4.9.  Receiving a Throughput Measurement Stop Reply

Upon the reception of a throughput measurement Stop Reply, the initiator MEP must inspect this message at first, if no unexpected field or value is found, and the received Control Code indicates successful operation at the peer MEP, then the initiator MEP should stop counting test packets and start calculating the test packet loss. Suppose the Tx Counter and Rx Counter for the initiator MEP are TxP1 and RxP1, and for the peer MEP are TxP2 and RxP2.

For two-way throughput measurement, the calculation formulas are as follow:

Packet Loss (forward) = TxP1 - RxP2

Packet Loss (reverse) = TxP2 - RxP1

For one-way throughput measurement, the calculation formula is as follow:

Packet Loss (one-way) = TxP1 - RxP2

If there is no any throughput measurement Stop Reply received after a while (such as 1 second), then specific error should be returned at the initiator MEP and no consequent action will happen.

4.10.  Consequent Actions and Searching Algorithm

Procedures for one run of test traffic sending and test packet loss calculation have been described above in details, but usually iterative reruns of the procedures are needed for a throughput measurement. Whether the rerun is needed or not is based on the calculated test packet loss and whether the expected measurement resolution is met. For one-way throughput measurement, if calculated Packet Loss (one-way) is equal to zero and the expected measurement resolution is met, then rerun is not needed (i.e. the one-way throughput measurement finished) and the current sending rate is the measured one-way throughput, otherwise the one-way throughput measurement proceeds. For two-way throughput measurement, if calculated forward Packet Loss and reverse Packet Loss are both equal to zero and the expected measurement resolution for both forward and reverse directions is met, then rerun is not needed (i.e. the two-way throughput measurement finished) and the current sending rate for forward/reverse direction is the measured forward/reverse throughput, otherwise the two-way throughput measurement proceeds, and in this case the sending rates for rerun should be calculated for forward direction and reverse direction respectively.

The simple and efficient binary search algorithm is RECOMMENDED to calculate the sending rate for the next run, which is the only changed test parameter compared with this run. How the binary search works, if packet loss is found for this run, it searches downwards for a lower rate which is halfway rate between the rate of this run and the known highest rate at which no packet loss is found; if no packet loss is found but the expected measurement resolution is not met for this run, it searches upwards for a higher rate which is halfway rate between the rate of this run and the known lowest rate at which packet loss is found; the measurement searches among higher and lower rates on the analogy of this, until it finds the rate at which no test packet is lost and expected measurement resolution is met, and this rate is the measured throughput. How to judge whether the expected measurement resolution is met or not, if the rate difference between the two consecutive runs (i.e. this run and the previous run), expressed as a percentage, is smaller than or equal to the specified measurement resolution, it's known as that the expected measurement resolution is met, otherwise it's not met.

For example, suppose to measure the throughput of a connection whose actual throughput is 70Mbps, the provisioned initial sending rate is 100Mbps and the specified measurement resolution is 0.1. Note that the initial sending rate should be higher than the actual throughput, otherwise the binary search is not applicable, and so it's often set to the maximum theoretical throughput of the measured connection. For the first run, packet loss is found, so for the second run, the sending rate will be calculated as (100+0)/2 = 50Mbps, no packet loss is found, then the resolution will be calculated as (100-50)/50 = 1, which is bigger than 0.1, the expected measurement resolution is not met, so for the third run, the sending rate will be calculated as (100+50)/2 = 75Mbps, packet loss is found, so for the fourth run, the sending rate will be calculated as (50+75)/2 = 62.5Mbps, no packet loss is found, then the resolution will be calculated as (75-62.5)/62.5 = 0.2, which is bigger than 0.1, the expected measurement resolution is not met, so for the fifth run, the sending rate will be calculated as (75+62.5)/2 = 68.75Mbps, no packet loss is found, then the resolution will be calculated as (68.75-62.5)/68.75 = 0.09, which is smaller than 0.1, the expected measurement resolution is met, so the measurement finished and the rate 68.75Mbps is the measured throughput.

Other algorithms than the binary search algorithm could also be used to search throughput in practice, e.g. increasing or decreasing the sending rate in a fixed step from a specified initial sending rate until the test packet loss appears or disappears.

5.  Throughput Measurement Time

The throughput measurement time is about the product of sending duration for one run and number of all run times. The sending duration for one run is provisioned before the throughput measurement starts, and the number of all run times is related to several factors, which include the provisioned initial sending rate, the applied searching algorithm and the specified expected measurement resolution. It's obvious that longer sending duration is provisioned, then longer throughput measurement time is needed, but it should be noted that longer sending duration can result in more precise measured throughput, so there should be a balance between them. Also obviously the expectations for shorter throughput measurement time and higher throughput measurement resolution are mutually exclusive, so the balance between them is needed too.

6.  Open Issue

Wouldn't it be better to have a threshold on the acceptable frame loss rate and not require absolutely no packet loss?

[Editor's note: As the authors know in practice when the throughput is measured by test devices, one threshold on the acceptable frame loss rate is configurable, but in [RFC1242] (Bradner, S., “Benchmarking terminology for network interconnection devices,” July 1991.) and [RFC2544] (Bradner, S. and J. McQuaid, “Benchmarking Methodology for Network Interconnect Devices,” March 1999.) the throughput is defined as that way no packet loss permitted.]

7.  IANA Considerations

To be added in a later version of this document.

8.  Security Considerations

To be added in a later version of this document.

9.  Acknowledgements

The authors would like to thank Huub (Huawei), Curtis (Infinera) and Ayal (celtro) for their valuable comments on this draft.

10.  References

10.1. Normative References

10.2. Informative References

Authors' Addresses