draft-ietf-ippm-tcp-throughput-tm-01.txt   draft-ietf-ippm-tcp-throughput-tm-02.txt 
Network Working Group B. Constantine Network Working Group B. Constantine
Internet-Draft JDSU Internet-Draft JDSU
Intended status: Informational G. Forget Intended status: Informational G. Forget
Expires: November 3, 2010 Bell Canada (Ext. Consultant) Expires: November 18, 2010 Bell Canada (Ext. Consultant)
L. Jorgenson L. Jorgenson
Apparent Networks Apparent Networks
Reinhard Schrage Reinhard Schrage
Schrage Consulting Schrage Consulting
May 3, 2010 May 18, 2010
TCP Throughput Testing Methodology TCP Throughput Testing Methodology
draft-ietf-ippm-tcp-throughput-tm-01.txt draft-ietf-ippm-tcp-throughput-tm-02.txt
Abstract Abstract
This memo describes a methodology for measuring sustained TCP This memo describes a methodology for measuring sustained TCP
throughput performance in an end-to-end managed network environment. throughput performance in an end-to-end managed network environment.
This memo is intended to provide a practical approach to help users This memo is intended to provide a practical approach to help users
validate the TCP layer performance of a managed network, which should validate the TCP layer performance of a managed network, which should
provide a better indication of end-user application level experience. provide a better indication of end-user application level experience.
In the methodology, various TCP and network parameters are identified In the methodology, various TCP and network parameters are identified
that should be tested as part of the network verification at the TCP that should be tested as part of the network verification at the TCP
layer. layer.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Creation date May 3, 2010. Drafts. Creation date May 18, 2010.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 3, 2010. This Internet-Draft will expire on November 18, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 27 skipping to change at page 2, line 27
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Goals of this Methodology. . . . . . . . . . . . . . . . . . . 4 2. Goals of this Methodology. . . . . . . . . . . . . . . . . . . 4
2.1 TCP Equilibrium State Throughput . . . . . . . . . . . . . 5 2.1 TCP Equilibrium State Throughput . . . . . . . . . . . . . 5
3. TCP Throughput Testing Methodology . . . . . . . . . . . . . . 6 3. TCP Throughput Testing Methodology . . . . . . . . . . . . . . 6
3.1 Determine Network Path MTU . . . . . . . . . . . . . . . . 7 3.1 Determine Network Path MTU . . . . . . . . . . . . . . . . 7
3.2. Baseline Round-trip Delay and Bandwidth. . . . . . . . . . 7 3.2. Baseline Round-trip Delay and Bandwidth. . . . . . . . . . 8
3.2.1 Techniques to Measure Round Trip Time . . . . . . . . 8 3.2.1 Techniques to Measure Round Trip Time . . . . . . . . 9
3.2.2 Techniques to Measure End-end Bandwidth . . . . . . . 8 3.2.2 Techniques to Measure End-end Bandwidth . . . . . . . 10
3.3. Single TCP Connection Throughput Tests . . . . . . . . . . .9 3.3. Single TCP Connection Throughput Tests . . . . . . . . . . 10
3.3.1 Interpretation of the Single Connection TCP 3.3.1 Interpretation of the Single Connection TCP
Throughput Results . . . . . . . . . . . . . . . . . . 13 Throughput Results . . . . . . . . . . . . . . . . . . 14
3.4. TCP MSS Throughput Testing . . . . . . . . . . . . . . . . 13 3.4. TCP MSS Throughput Testing . . . . . . . . . . . . . . . . 14
3.4.1 MSS Size Testing Method. . . . . . . . . . . . . . . 13 3.4.1 MSS Size Testing Method. . . . . . . . . . . . . . . 14
3.4.2 Interpretation of TCP MSS Throughput Results. . . . . 14 3.4.2 Interpretation of TCP MSS Throughput Results. . . . . 15
3.5. Multiple TCP Connection Throughput Tests. . . . . . . . . . 15 3.5. Multiple TCP Connection Throughput Tests. . . . . . . . . . 16
3.5.1 Multiple TCP Connections - below Link Capacity . . . . 15 3.5.1 Multiple TCP Connections - below Link Capacity . . . . 16
3.5.2 Multiple TCP Connections - over Link Capacity. . . . . 16 3.5.2 Multiple TCP Connections - over Link Capacity. . . . . 17
3.5.3 Interpretation of Multiple TCP Connection Results. . . 16 3.5.3 Interpretation of Multiple TCP Connection Results. . . 17
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
Even though RFC2544 was meant to benchmark network equipment and Even though RFC2544 was meant to benchmark network equipment and
used by network equipment manufacturers (NEMs), network providers used by network equipment manufacturers (NEMs), network providers
have used it to benchmark operational networks in order to have used it to benchmark operational networks in order to
verify SLAs (Service Level Agreements) before turning on a service verify SLAs (Service Level Agreements) before turning on a service
to their business customers. Testing an operational network prior to to their business customers. Testing an operational network prior to
customer activation is referred to as "turn-up" testing and the SLA customer activation is referred to as "turn-up" testing and the SLA
is generally Layer 2/3 packet throughput, delay, loss and is generally Layer 2/3 packet throughput, delay, loss and
skipping to change at page 7, line 25 skipping to change at page 7, line 25
- Most importantly, the TCP test host must be capable of generating - Most importantly, the TCP test host must be capable of generating
and receiving stateful TCP test traffic at the full link speed of the and receiving stateful TCP test traffic at the full link speed of the
network under test. This requirement is very serious and may require network under test. This requirement is very serious and may require
custom test equipment, especially on 1 GigE and 10 GigE networks. custom test equipment, especially on 1 GigE and 10 GigE networks.
3.1. Determine Network Path MTU 3.1. Determine Network Path MTU
TCP implementations should use Path MTU Discovery techniques (PMTUD), TCP implementations should use Path MTU Discovery techniques (PMTUD),
but this technique does not always prove reliable in real world but this technique does not always prove reliable in real world
situations. Since PMTUD relies on ICMP messages (to inform the host situations. Since PMTUD relies on ICMP messages (to inform the host
that unfragmented transmission cannot occur), PMTUD is not always that unfragmented transmission cannot occur), it's not always
reliable since many network managers completely disable ICMP. reliable since many network managers completely disable ICMP.
Increasingly network providers and enterprises are instituting fixed Increasingly, network providers and enterprises are instituting fixed
MTU sizes on the hosts to eliminate TCP fragmentation issues in the MTU sizes on the hosts to eliminate TCP fragmentation issues.
application.
Packetization Layer Path MTU Discovery or PLPMTUD (RFC4821) should Packetization Layer Path MTU Discovery or PLPMTUD (RFC4821) should
be conducted to verify the minimum network path MTU. Conducting be conducted to verify the minimum network path MTU. PLPMTUD can
the PLPMTUD test establishes the upper limit upon the MTU, which be used with or without ICMP. The following sections provide a
establishes the upper limit for the MSS in the subsequent test steps. summary of the PLPMTUD approach and an example using the TCP
protocol.
RFC4821 specifies a search_high and search_low parameter for the
MTU. As specified in RFC4821, a value of 1024 is a generally safe
value to choose for search_low in modern networks.
It is important to determine the overhead of the links in the path,
and then to select a TCP MSS size corresponding to the Layer 3 MTU.
For example, if the MTU is 1024 bytes and the TCP/IP headers are 40
bytes, then the MSS would be set to 984 bytes.
An example scenario is a network where the actual path MTU is 1240
bytes. The TCP client probe MUST be capable of setting the MSS for
the probe packets and could start at MSS = 984 (which corresponds
to an MTU size of 1024 bytes).
The TCP client probe would open a TCP connection and advertise the
MSS as 984. Note that the client probe MUST generate these packets
with the DF bit set. The TCP client probe then sends test traffic
per a nominal window size (8KB, etc.). The window size should be
kept small to minimize the possibility of congesting the network,
which could induce congestive loss. The duration of the test should
also be short (10-30 seconds), again to minimize congestive effects
during the test.
In the example of a 1240 byte path MTU, probing with an MSS equal to
984 would yield a successful probe and the test client packets would
be successfully transferred to the test server.
Also note that the test client MUST verify that the MSS advertised
is indeed negotiated. Network devices with built-in Layer 4
capabilities can intercede during the connection establishment
process and reduce the advertised MSS to avoid fragmentation. This
is certainly a desirable feature from a network perspective, but
can yield erroneous test results if the client test probe does not
confirm the negotiated MSS.
The next test probe would use the search_high value and this would
be set to MSS = 1460 to correspond to a 1500 byte MTU. In this
example, the test client would retransmit based upon time-outs (since
no ACKs will be received from the test server). This test probe is
marked as a conclusive failure if none of the test packets are
ACK'ed. If any of the test packets are ACK'ed, congestive network
may be the cause and the test probe is not conclusive. Re-testing
at other times of the day is recommended to further isolate.
The test is repeated until the desired granularity of the MTU is
discovered. The method can yield precise results at the expense of
probing time. One approach would be to reduce the probe size to
half between the unsuccessful search_high and successful search_low
value, and increase by increments of 1/2 when seeking the upper
limit.
3.2. Baseline Round-trip Delay and Bandwidth 3.2. Baseline Round-trip Delay and Bandwidth
Before stateful TCP testing can begin, it is important to baseline Before stateful TCP testing can begin, it is important to baseline
the round trip delay and bandwidth of the network to be tested. the round trip delay and bandwidth of the network to be tested.
These measurements provide estimates of the ideal TCP window size, These measurements provide estimates of the ideal TCP window size,
which will be used in subsequent test steps. which will be used in subsequent test steps. These latency and
bandwidth tests should be run over a long enough period of time to
characterize the performance of the network over the course of a
meaningful time period.
These latency and bandwidth tests should be run over a long enough One example would be to take samples during various times of the work
period of time to characterize the performance of the network over day. The goal would be to determine a representative minimum, average,
the course of a meaningful time period. One example would and maximum RTD and bandwidth for the network under test. Topology
be to take samples during various times of the work day. The goal changes are to be avoided during this time of initial convergence
would be to determine a representative minimum, average, and maximum (e.g. in crossing BGP4 boundaries).
RTD and bandwidth for the network under test. Topology changes are
to be avoided during this time of initial convergence (e.g. in
crossing BGP4 boundaries).
In some cases, baselining bandwidth may not be required, since a In some cases, baselining bandwidth may not be required, since a
network provider's end-to-end topology may be well enough defined. network provider's end-to-end topology may be well enough defined.
3.2.1 Techniques to Measure Round Trip Time 3.2.1 Techniques to Measure Round Trip Time
We follow in the definitions used in the references of the appendix; We follow in the definitions used in the references of the appendix;
hence Round Trip Time (RTT) is the time elapsed between the clocking hence Round Trip Time (RTT) is the time elapsed between the clocking
in of the first bit of a payload packet to the receipt of the last in of the first bit of a payload packet to the receipt of the last
bit of the corresponding acknowledgement. Round Trip Delay (RTD) bit of the corresponding acknowledgement. Round Trip Delay (RTD)
 End of changes. 13 change blocks. 
36 lines changed or deleted 87 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/