draft-ietf-bmwg-ca-bench-meth-02.txt   draft-ietf-bmwg-ca-bench-meth-03.txt 
Internet Engineering Task Force M. Hamilton Internet Engineering Task Force M. Hamilton
Internet-Draft BreakingPoint Systems Internet-Draft BreakingPoint Systems
Intended status: Informational S. Banks Intended status: Informational S. Banks
Expires: January 17, 2013 Cisco Systems Expires: February 1, 2013 Cisco Systems
July 16, 2012 July 31, 2012
Benchmarking Methodology for Content-Aware Network Devices Benchmarking Methodology for Content-Aware Network Devices
draft-ietf-bmwg-ca-bench-meth-02 draft-ietf-bmwg-ca-bench-meth-03
Abstract Abstract
This document defines a set of test scenarios and metrics that can be This document defines a set of test scenarios and metrics that can be
used to benchmark content-aware network devices. The scenarios in used to benchmark content-aware network devices. The scenarios in
the following document are intended to more accurately predict the the following document are intended to more accurately predict the
performance of these devices when subjected to dynamic traffic performance of these devices when subjected to dynamic traffic
patterns. This document will operate within the constraints of the patterns. This document will operate within the constraints of the
Benchmarking Working Group charter, namely black box characterization Benchmarking Working Group charter, namely black box characterization
in a laboratory environment. in a laboratory environment.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on January 17, 2013. This Internet-Draft will expire on February 1, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 21 skipping to change at page 2, line 21
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Test Setup . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Test Setup . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Test Considerations . . . . . . . . . . . . . . . . . . . 6 3.1. Test Considerations . . . . . . . . . . . . . . . . . . . 6
3.2. Clients and Servers . . . . . . . . . . . . . . . . . . . 6 3.2. Clients and Servers . . . . . . . . . . . . . . . . . . . 6
3.3. Traffic Generation Requirements . . . . . . . . . . . . . 6 3.3. Traffic Generation Requirements . . . . . . . . . . . . . 6
3.4. Discussion of Network Limitations . . . . . . . . . . . . 6 3.4. Discussion of Network Limitations . . . . . . . . . . . . 6
3.5. Framework for Traffic Specification . . . . . . . . . . . 8 3.5. Framework for Traffic Specification . . . . . . . . . . . 8
3.6. Multiple Client/Server Testing . . . . . . . . . . . . . . 8 3.6. Multiple Client/Server Testing . . . . . . . . . . . . . . 8
3.7. Device Configuration Considerations . . . . . . . . . . . 8 3.7. Device Configuration Considerations . . . . . . . . . . . 8
3.7.1. Network Addressing . . . . . . . . . . . . . . . . . . 8 3.7.1. Network Addressing . . . . . . . . . . . . . . . . . . 9
3.7.2. Network Address Translation . . . . . . . . . . . . . 9 3.7.2. Network Address Translation . . . . . . . . . . . . . 9
3.7.3. TCP Stack Considerations . . . . . . . . . . . . . . . 9 3.7.3. TCP Stack Considerations . . . . . . . . . . . . . . . 9
3.7.4. Other Considerations . . . . . . . . . . . . . . . . . 9 3.7.4. Other Considerations . . . . . . . . . . . . . . . . . 9
4. Benchmarking Tests . . . . . . . . . . . . . . . . . . . . . . 9 4. Benchmarking Tests . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Maximum Application Session Establishment Rate . . . . . . 9 4.1. Maximum Application Session Establishment Rate . . . . . . 10
4.1.1. Objective . . . . . . . . . . . . . . . . . . . . . . 10 4.1.1. Objective . . . . . . . . . . . . . . . . . . . . . . 10
4.1.2. Setup Parameters . . . . . . . . . . . . . . . . . . . 10 4.1.2. Setup Parameters . . . . . . . . . . . . . . . . . . . 10
4.1.2.1. Application-Layer Parameters . . . . . . . . . . . 10
4.1.3. Procedure . . . . . . . . . . . . . . . . . . . . . . 10 4.1.3. Procedure . . . . . . . . . . . . . . . . . . . . . . 10
4.1.4. Measurement . . . . . . . . . . . . . . . . . . . . . 10 4.1.4. Measurement . . . . . . . . . . . . . . . . . . . . . 10
4.1.4.1. Maximum Application Flow Rate . . . . . . . . . . 10 4.1.4.1. Maximum Application Flow Rate . . . . . . . . . . 10
4.1.4.2. Application Flow Duration . . . . . . . . . . . . 11 4.1.4.2. Application Flow Duration . . . . . . . . . . . . 11
4.1.4.3. Application Efficiency . . . . . . . . . . . . . . 11 4.1.4.3. Application Efficiency . . . . . . . . . . . . . . 11
4.1.4.4. Application Flow Latency . . . . . . . . . . . . . 11 4.1.4.4. Application Flow Latency . . . . . . . . . . . . . 11
4.2. Application Throughput . . . . . . . . . . . . . . . . . . 11 4.2. Application Throughput . . . . . . . . . . . . . . . . . . 11
4.2.1. Objective . . . . . . . . . . . . . . . . . . . . . . 11 4.2.1. Objective . . . . . . . . . . . . . . . . . . . . . . 11
4.2.2. Setup Parameters . . . . . . . . . . . . . . . . . . . 11 4.2.2. Setup Parameters . . . . . . . . . . . . . . . . . . . 11
4.2.2.1. Parameters . . . . . . . . . . . . . . . . . . . . 11
4.2.3. Procedure . . . . . . . . . . . . . . . . . . . . . . 12 4.2.3. Procedure . . . . . . . . . . . . . . . . . . . . . . 12
4.2.4. Measurement . . . . . . . . . . . . . . . . . . . . . 12 4.2.4. Measurement . . . . . . . . . . . . . . . . . . . . . 12
4.2.4.1. Maximum Throughput . . . . . . . . . . . . . . . . 12 4.2.4.1. Maximum Throughput . . . . . . . . . . . . . . . . 12
4.2.4.2. Maximum Application Flow Rate . . . . . . . . . . 12 4.2.4.2. Maximum Application Flow Rate . . . . . . . . . . 12
4.2.4.3. Application Flow Duration . . . . . . . . . . . . 12 4.2.4.3. Application Flow Duration . . . . . . . . . . . . 12
4.2.4.4. Application Efficiency . . . . . . . . . . . . . . 12 4.2.4.4. Application Efficiency . . . . . . . . . . . . . . 12
4.2.4.5. Packet Loss . . . . . . . . . . . . . . . . . . . 12 4.2.4.5. Packet Loss . . . . . . . . . . . . . . . . . . . 12
4.2.4.6. Application Flow Latency . . . . . . . . . . . . . 12 4.2.4.6. Application Flow Latency . . . . . . . . . . . . . 12
4.3. Malformed Traffic Handling . . . . . . . . . . . . . . . . 13 4.3. Malformed Traffic Handling . . . . . . . . . . . . . . . . 13
4.3.1. Objective . . . . . . . . . . . . . . . . . . . . . . 13 4.3.1. Objective . . . . . . . . . . . . . . . . . . . . . . 13
skipping to change at page 3, line 6 skipping to change at page 3, line 4
4.2.4.2. Maximum Application Flow Rate . . . . . . . . . . 12 4.2.4.2. Maximum Application Flow Rate . . . . . . . . . . 12
4.2.4.3. Application Flow Duration . . . . . . . . . . . . 12 4.2.4.3. Application Flow Duration . . . . . . . . . . . . 12
4.2.4.4. Application Efficiency . . . . . . . . . . . . . . 12 4.2.4.4. Application Efficiency . . . . . . . . . . . . . . 12
4.2.4.5. Packet Loss . . . . . . . . . . . . . . . . . . . 12 4.2.4.5. Packet Loss . . . . . . . . . . . . . . . . . . . 12
4.2.4.6. Application Flow Latency . . . . . . . . . . . . . 12 4.2.4.6. Application Flow Latency . . . . . . . . . . . . . 12
4.3. Malformed Traffic Handling . . . . . . . . . . . . . . . . 13 4.3. Malformed Traffic Handling . . . . . . . . . . . . . . . . 13
4.3.1. Objective . . . . . . . . . . . . . . . . . . . . . . 13 4.3.1. Objective . . . . . . . . . . . . . . . . . . . . . . 13
4.3.2. Setup Parameters . . . . . . . . . . . . . . . . . . . 13 4.3.2. Setup Parameters . . . . . . . . . . . . . . . . . . . 13
4.3.3. Procedure . . . . . . . . . . . . . . . . . . . . . . 13 4.3.3. Procedure . . . . . . . . . . . . . . . . . . . . . . 13
4.3.4. Measurement . . . . . . . . . . . . . . . . . . . . . 13 4.3.4. Measurement . . . . . . . . . . . . . . . . . . . . . 13
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 7.1. Normative References . . . . . . . . . . . . . . . . . . . 14
7.2. Informative References . . . . . . . . . . . . . . . . . . 15 7.2. Informative References . . . . . . . . . . . . . . . . . . 15
7.3. URL References . . . . . . . . . . . . . . . . . . . . . . 15
Appendix A. Example Traffic Mix . . . . . . . . . . . . . . . . . 15 Appendix A. Example Traffic Mix . . . . . . . . . . . . . . . . . 15
Appendix B. Malformed Traffic Algorithm . . . . . . . . . . . . . 17 Appendix B. Malformed Traffic Algorithm . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
Content-aware and deep packet inspection (DPI) device deployments Content-aware and deep packet inspection (DPI) device deployments
have grown significantly in recent years. No longer are devices have grown significantly in recent years. No longer are devices
simply using Ethernet and IP headers to make forwarding decisions. simply using Ethernet and IP headers to make forwarding decisions.
This class of device now uses application-specific data to make these This class of device now uses application-specific data to make these
skipping to change at page 5, line 46 skipping to change at page 5, line 46
the content-aware category. While this list may become obsolete, the content-aware category. While this list may become obsolete,
these are a subset of devices that fall under this scope of testing. these are a subset of devices that fall under this scope of testing.
3. Test Setup 3. Test Setup
This document will be applicable to most test configurations and will This document will be applicable to most test configurations and will
not be confined to a discussion on specific test configurations. not be confined to a discussion on specific test configurations.
Since each DUT/SUT will have their own unique configuration, users Since each DUT/SUT will have their own unique configuration, users
SHOULD configure their device with the same parameters that would be SHOULD configure their device with the same parameters that would be
used in the actual deployment of the device or a typical deployment, used in the actual deployment of the device or a typical deployment,
if the actual deployment is unknown. In order to improve if the actual deployment is unknown. A summary of the DUT
repeatability, the DUT configuration SHOULD be published with the configuration MUST be published with the final benchmarking results.
final benchmarking results. If available, command-line scripts used In order to improve repeatability, the published configuration
to configured the DUT and any configuration information for the information SHOULD include command-line scripts used to configure the
tester SHOULD be published with the final results DUT, if any, and SHOULD also include any configuration information
for the test equipment used."
3.1. Test Considerations 3.1. Test Considerations
3.2. Clients and Servers 3.2. Clients and Servers
Content-aware device testing SHOULD involve multiple clients and Content-aware device testing SHOULD involve multiple clients and
multiple servers. As with RFC 3511 [4], this methodology will use multiple servers. As with RFC 3511 [4], this methodology will use
the terms virtual clients/servers because both the client and server the terms virtual clients/servers because both the client and server
will be represented by the tester and not actual clients/servers. will be represented by the tester and not actual clients/servers.
Similarly defined in RFC 3511 [4], a data source may emulate multiple Similarly defined in RFC 3511 [4], a data source may emulate multiple
skipping to change at page 6, line 28 skipping to change at page 6, line 29
RFC 2544 Appendix C [2] and RFC 5180 Section 5.2 [8] respectively and RFC 2544 Appendix C [2] and RFC 5180 Section 5.2 [8] respectively and
SHOULD be consulted prior to testing. SHOULD be consulted prior to testing.
3.3. Traffic Generation Requirements 3.3. Traffic Generation Requirements
The explicit purposes of content-aware devices vary widely, but these The explicit purposes of content-aware devices vary widely, but these
devices use information deeper inside the application flow to make devices use information deeper inside the application flow to make
decisions and classify traffic. This methodology will utilize decisions and classify traffic. This methodology will utilize
traffic flows that resemble real application traffic without traffic flows that resemble real application traffic without
utilizing captures from live production networks. Application Flows, utilizing captures from live production networks. Application Flows,
as defined in RFC 2722 [9] are able to be well-defined without simply as defined in Section 1.1 RFC 2724 [9] are able to be well-defined
referring to a network capture. An example traffic template is without simply referring to a network capture. An example traffic
defined and listed in Appendix A of this document. A user of this template is defined and listed in Appendix A of this document. A
methodology is free to utilize the example mix as provided in the user of this methodology is free to utilize the example mix as
appendix. If a user of this methodology understands the traffic provided in the appendix. If a user of this methodology understands
patterns in their production network, that user MAY use the template the traffic patterns in their production network, that user MAY use
provided in Appendix A to describe a traffic mix appropriate for the template provided in Appendix A to describe a traffic mix
their environment. appropriate for their environment. In all cases, users MUST report
the traffic mix used in the test, and SHOULD report this using a
template similar to that in Appendix A.
The test tool SHOULD be able to create application flows between The test tool SHOULD be able to create application flows between
every client and server, regardless of direction. The tester SHOULD every client and server, regardless of direction. The tester SHOULD
be able to open TCP connections on multiple destination ports and be able to open TCP connections on multiple destination ports and
SHOULD be able to direct UDP traffic to multiple destination ports. SHOULD be able to direct UDP traffic to multiple destination ports.
3.4. Discussion of Network Limitations 3.4. Discussion of Network Limitations
Prior to executing the methodology as outlined in the following Prior to executing the methodology as outlined in the following
sections, it is imperative to understand the implications of sections, it is imperative to understand the implications of
skipping to change at page 8, line 20 skipping to change at page 8, line 24
This example illustrates why a user of this methodology SHOULD This example illustrates why a user of this methodology SHOULD
benchmark each application variant individually to ensure that the benchmark each application variant individually to ensure that the
cause of a measured limit is fully understood cause of a measured limit is fully understood
3.5. Framework for Traffic Specification 3.5. Framework for Traffic Specification
The following table SHOULD be specified for each application flow The following table SHOULD be specified for each application flow
variant. variant.
o Flow Size in Bits o Data Exchanged By Flow, Bits
o Percentage of Aggregate Flows: 25% o Offered Percentage of Total Flows
o Transport Protocol(s): TCP,UDP o Transport Protocol(s)
o Destination Port(s): 80 o Destination Port(s)
3.6. Multiple Client/Server Testing 3.6. Multiple Client/Server Testing
In actual network deployments, connections are being established In actual network deployments, connections are being established
between multiple clients and multiple servers simultaneously. Device between multiple clients and multiple servers simultaneously. Device
vendors have been known to optimize the operation of their devices vendors have been known to optimize the operation of their devices
for easily defined patterns. The connection sequence ordering for easily defined patterns. The connection sequence ordering
scenarios a device will see on a network will likely be much less scenarios a device will see on a network will likely be much less
deterministic. In fact, many application flows have multiple layer 4 deterministic. In fact, many application flows have multiple layer 4
connections within a single flow, with client and server reversing connections within a single flow, with client and server reversing
roles. This methodology makes no assumptions about flow initiation roles. Flow initiation SHOULD be in a pseudo-random manner across
sequence across multiple ports. ingress ports.
3.7. Device Configuration Considerations 3.7. Device Configuration Considerations
The configuration of the DUT may have an effect on the observed The configuration of the DUT may have an effect on the observed
results of the following methodology. A comprehensive, but certainly results of the following methodology. A comprehensive, but certainly
not exhaustive, list of potential considerations is listed below. not exhaustive, list of potential considerations is listed below.
3.7.1. Network Addressing 3.7.1. Network Addressing
The IANA has issued a range of IP addresses to the BMWG for purposes The IANA has issued a range of IP addresses to the BMWG for purposes
skipping to change at page 10, line 14 skipping to change at page 10, line 18
4.1.1. Objective 4.1.1. Objective
To determine the maximum rate through which a device is able to To determine the maximum rate through which a device is able to
establish and complete application flows as defined by establish and complete application flows as defined by
draft-ietf-bmwg-ca-bench-term-00. draft-ietf-bmwg-ca-bench-term-00.
4.1.2. Setup Parameters 4.1.2. Setup Parameters
The following parameters SHOULD be used and reported for all tests: The following parameters SHOULD be used and reported for all tests:
4.1.2.1. Application-Layer Parameters
For each application protocol in use during the test run, the table For each application protocol in use during the test run, the table
provided in Section 3.5 SHOULD be published. provided in Section 3.5 SHOULD be published.
4.1.3. Procedure 4.1.3. Procedure
The test SHOULD generate application network traffic that meets the The test SHOULD generate application network traffic that meets the
conditions of Section 3.3. The traffic pattern SHOULD begin with an conditions of Section 3.3. The traffic pattern SHOULD begin with an
application flow rate of 10% of expected maximum. The test SHOULD be application flow rate of 10% of expected maximum. The test SHOULD be
configured to increase the attempt rate in units of 10% up through configured to increase the attempt rate in units of 10% up through
110% of expected maximum. In the case where expected maximum is 110% of expected maximum. In the case where expected maximum is
skipping to change at page 11, line 46 skipping to change at page 11, line 46
4.2. Application Throughput 4.2. Application Throughput
4.2.1. Objective 4.2.1. Objective
To determine the maximum rate through which a device is able to To determine the maximum rate through which a device is able to
forward bits when using application flows as defined in the previous forward bits when using application flows as defined in the previous
sections. sections.
4.2.2. Setup Parameters 4.2.2. Setup Parameters
The following parameters SHOULD be used and reported for all tests: The same parameter reporting procedure as described in Section 4.1.2
SHOULD be used for all tests.
4.2.2.1. Parameters
The same parameters as described in Section 4.1.2 SHOULD be used.
4.2.3. Procedure 4.2.3. Procedure
This test will attempt to send application flows through the device This test will attempt to send application flows through the device
at a flow rate of 30% of the maximum, as observed in Section 4.1. at a flow rate of 30% of the maximum, as observed in Section 4.1.
This procedure MAY be repeated with the results from each iteration This procedure MAY be repeated with the results from each iteration
averaged together. averaged together.
4.2.4. Measurement 4.2.4. Measurement
skipping to change at page 14, line 44 skipping to change at page 14, line 44
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[7] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", [7] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues",
RFC 3234, February 2002. RFC 3234, February 2002.
[8] Popoviciu, C., Hamza, A., Van de Velde, G., and D. Dugatkin, [8] Popoviciu, C., Hamza, A., Van de Velde, G., and D. Dugatkin,
"IPv6 Benchmarking Methodology for Network Interconnect "IPv6 Benchmarking Methodology for Network Interconnect
Devices", RFC 5180, May 2008. Devices", RFC 5180, May 2008.
[9] Brownlee, N., Mills, C., and G. Ruth, "Traffic Flow [9] Handelman, S., Stibler, S., Brownlee, N., and G. Ruth, "RTFM:
Measurement: Architecture", RFC 2722, October 1999. New Attributes for Traffic Flow Measurement", RFC 2724,
October 1999.
[10] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. [10] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E.
Lear, "Address Allocation for Private Internets", BCP 5, Lear, "Address Allocation for Private Internets", BCP 5,
RFC 1918, February 1996. RFC 1918, February 1996.
[11] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap for [11] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap for
Transmission Control Protocol (TCP) Specification Documents", Transmission Control Protocol (TCP) Specification Documents",
RFC 4614, September 2006. RFC 4614, September 2006.
[12] Mathis, M. and M. Allman, "A Framework for Defining Empirical [12] Mathis, M. and M. Allman, "A Framework for Defining Empirical
skipping to change at page 15, line 23 skipping to change at page 15, line 23
"Framework for TCP Throughput Testing", RFC 6349, August 2011. "Framework for TCP Throughput Testing", RFC 6349, August 2011.
7.2. Informative References 7.2. Informative References
[14] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [14] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[15] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [15] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
7.3. URL References
[16] Sandvine Corporation, "http://www.sandvine.com/general/
document.download.asp?docID=58&sourceID=0", 2012.
Appendix A. Example Traffic Mix Appendix A. Example Traffic Mix
This appendix shows an example case of a protocol mix that may be This appendix shows an example case of a protocol mix that may be
used with this methodology. This mix closely represents the research used with this methodology. This mix closely represents the research
published by Sandvine in their biannual report for the first half of published by Sandvine [16] in their biannual report for the first
2012 on North American fixed access service provider networks. half of 2012 on North American fixed access service provider
networks.
+------------+------------------+--------------------+--------+ +------------+------------------+--------------------+--------+
| Direction | Application Flow | Options | Value | | Direction | Application Flow | Options | Value |
+------------+------------------+--------------------+--------+ +------------+------------------+--------------------+--------+
| Upstream | BitTorrent | | | | Upstream | BitTorrent | | |
| | | Avg Flow Size (L7) | 512 MB | | | | Avg Flow Size (L7) | 512 MB |
| | | Flow Percentage | 44.4% | | | | Flow Percentage | 44.4% |
| | HTTP | | | | | HTTP | | |
| | | Avg Flow Size (L7) | 128 kB | | | | Avg Flow Size (L7) | 128 kB |
| | | Flow Percentage | 7.3% | | | | Flow Percentage | 7.3% |
 End of changes. 21 change blocks. 
38 lines changed or deleted 43 lines changed or added

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