draft-ietf-bmwg-mcastm-04.txt   draft-ietf-bmwg-mcastm-05.txt 
Network Working Group Hardev Soor Network Working Group Hardev Soor
INTERNET-DRAFT Debra Stopp INTERNET-DRAFT Debra Stopp
Expires in: January 2001 IXIA Expires in: March 2001 IXIA
Ralph Daniels Ralph Daniels
Netcom Systems Netcom Systems
July 2000 December 2000
Methodology for IP Multicast Benchmarking Methodology for IP Multicast Benchmarking
<draft-ietf-bmwg-mcastm-04.txt> <draft-ietf-bmwg-mcastm-05.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
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. Drafts.
skipping to change at page 4, line 43 skipping to change at page 4, line 43
networking environment. While the multicast traffic is transmitted networking environment. While the multicast traffic is transmitted
from one source to multiple destinations, the unicast traffic MAY be from one source to multiple destinations, the unicast traffic MAY be
evenly distributed across the DUT/SUT architecture. In addition, the evenly distributed across the DUT/SUT architecture. In addition, the
DUT/SUT SHOULD learn the appropriate unicast IP addresses, either by DUT/SUT SHOULD learn the appropriate unicast IP addresses, either by
sending ARP frames from each unicast address, sending a RIP packet or sending ARP frames from each unicast address, sending a RIP packet or
by assigning static entries into the DUT/SUT address table. by assigning static entries into the DUT/SUT address table.
The mixture of multicast and unicast traffic MUST be set up in one of The mixture of multicast and unicast traffic MUST be set up in one of
two ways: two ways:
a) As a percent of the total traffic flow resulting in a ratio. a) As a percentage of the total traffic flow employing maximum
For example, 20 percent multicast traffic to 80 percent unicast bandwidth utilization. Thus, each type of traffic is
traffic. transmitted at the maximum available bandwidth. This also
implies that the offered load, regardless of the type of
traffic, remains constant.
b) In evenly distributed bursts of multicast and unicast b) As a percentage of the total traffic flow employing a
traffic, resulting in a 50-50 ratio of multicast to unicast proportionate bandwidth utilization. Thus, each type of
traffic. traffic is transmitted at a fraction of the available
bandwidth proportional to the specified ratio. This also
implies that the offered load for each traffic type varies in
proportion to its specified ratio.
The transmission of the frames MUST be set up so that they form a The transmission of the frames MUST be set up so that they form a
deterministic distribution while still maintaining the specified deterministic distribution while still maintaining the specified
forwarding rates. See Appendix A for a discussion on non-homogenous forwarding rates. See Appendix A for a discussion on non-homogenous
vs. homogenous packet distribution. vs. homogenous packet distribution.
Similar to the Frame loss rate test in RFC 2544, the first trial Similar to the Frame loss rate test in RFC 2544, the first trial
SHOULD be run for the frame rate that corresponds to 100% of the SHOULD be run for the frame rate that corresponds to 100% of the
maximum rate for the frame size on the input media. Repeat the maximum rate for the frame size on the input media. Repeat the
procedure for the rate that corresponds to 90% of the maximum rate procedure for the rate that corresponds to 90% of the maximum rate
skipping to change at page 8, line 50 skipping to change at page 8, line 56
Figure 4 Figure 4
-------- --------
In Figure 4, the encapsulation process takes place in DUT/SUT A. In Figure 4, the encapsulation process takes place in DUT/SUT A.
This may effect the throughput of the DUT/SUT B. Therefore, two This may effect the throughput of the DUT/SUT B. Therefore, two
test ports should be used to separate the encapsulation and test ports should be used to separate the encapsulation and
decapsulation processes. Client A is replaced with the test port A decapsulation processes. Client A is replaced with the test port A
which will generate a multicast frame that will be encapsulated by which will generate a multicast frame that will be encapsulated by
DUT/SUT A. Another test port B is inserted between DUT/SUT A and DUT/SUT A. Another test port B is inserted between DUT/SUT A and
DUT/SUT B that will receive the encapsulated frames and forward it DUT/SUT B that will also receive the encapsulated frames as they
to DUT/SUT B. Test port C will receive the decapsulated frames and are forwarded by DUT/SUT A to DUT/SUT B. Test port B may be used
measure the throughput. to monitor the throughput of the encapsulated frames as they
traverse the tunnel. Test port C will receive the decapsulated
frames and measure the throughput.
Result Result
Parameters to be measured SHOULD include the frame loss and Parameters to be measured SHOULD include the frame loss and
percent loss per destination port for each multicast group percent loss per destination port for each multicast group
address. address.
In addition, the transmit and receive rates in frames per second In addition, the transmit and receive rates in frames per second
for each source and destination port for all multicast groups, for each source and destination port for all multicast groups,
together with the number of frames transmitted and received per together with the number of frames transmitted and received per
port per multicast groups SHOULD be reported. port per multicast groups SHOULD be reported.
4.4.3 Re-encapsulation Throughput 4.4.3 Re-encapsulation Throughput
skipping to change at page 10, line 26 skipping to change at page 10, line 31
The set of individual latencies from a single input port on the The set of individual latencies from a single input port on the
DUT/SUT or SUT to all tested ports belonging to the destination DUT/SUT or SUT to all tested ports belonging to the destination
multicast group. multicast group.
Procedure Procedure
According to RFC 2544, a tagged frame is sent half way through the According to RFC 2544, a tagged frame is sent half way through the
transmission that contains a timestamp used for calculation of transmission that contains a timestamp used for calculation of
latency. In the multicast situation, a tagged frame is sent to all latency. In the multicast situation, a tagged frame is sent to all
destinations for each multicast group and latency calculated on a per destinations for each multicast group and latency calculated on a per
multicast group basis. Note that this test MUST be run using the multicast group basis.
transmission rate that is less than the multicast throughput of the
DUT/SUT. Also, the test should take into account the DUT's/SUT's need Note that this test MUST be run using the transmission rate that is
to cache the traffic in its IP cache, fastpath cache or shortcut less than the multicast throughput of the DUT/SUT. In addition, the
tables since the initial part of the traffic will be utilized to transmission rate SHOULD be less than the rate at which the buffers
build these tables. are depleted in order to avoid measuring buffer depth. The test
should also take into account the DUT's/SUT's need to cache the
traffic in its IP cache, fastpath cache or shortcut tables since the
initial part of the traffic will be utilized to build these tables.
Result Result
The parameter to be measured is the latency value for each multicast The parameter to be measured is the latency value for each multicast
group address per destination port. An aggregate latency MAY also be group address per destination port. An aggregate latency MAY also be
reported. reported. In addition, the transmit rate in frames per second for
each source port SHOULD be reported.
5.2 Min/Max/Average Multicast Latency 5.2 Min/Max/Average Multicast Latency
Definition Definition
The difference between the maximum latency measurement and the The difference between the maximum latency measurement and the
minimum latency measurement from the set of latencies produced by the minimum latency measurement from the set of latencies produced by the
Multicast Latency benchmark. Multicast Latency benchmark.
Procedure Procedure
First determine the throughput for DUT/SUT at each of the listed First determine the throughput for DUT/SUT at each of the listed
frame sizes determined by the forwarding and throughput tests of frame sizes determined by the forwarding and throughput tests of
section 4. Send a stream of frames to a fixed number of multicast section 4. Send a stream of frames to a fixed number of multicast
groups through the DUT at the determined throughput rate. An groups through the DUT at the determined throughput rate. An
skipping to change at page 11, line 14 skipping to change at page 11, line 25
identification of the transmitted frame on the receive side, the type identification of the transmitted frame on the receive side, the type
of tag being implementation dependent. of tag being implementation dependent.
Latencies for each transmitted frame are calculated based on the Latencies for each transmitted frame are calculated based on the
description of latencies in RFC 2544. The average latency is the description of latencies in RFC 2544. The average latency is the
total of all accumulated latency values divided by the total number total of all accumulated latency values divided by the total number
of those values. The minimum latency is the smallest latency; the of those values. The minimum latency is the smallest latency; the
maximum latency is the largest latency of all accumulated latency maximum latency is the largest latency of all accumulated latency
values. values.
Note that this test MUST be run using the transmission rate that is
less than the multicast throughput of the DUT/SUT. In addition, the
transmission rate SHOULD be less than the rate at which the buffers
are depleted in order to avoid measuring buffer depth. The test
should also take into account the DUT's/SUT's need to cache the
traffic in its IP cache, fastpath cache or shortcut tables since the
initial part of the traffic will be utilized to build these tables.
Results Results
The parameters to be measured are the minium, maximum and average The parameters to be measured are the minium, maximum and average
latency values for each multicast group address per destination port. latency values for each multicast group address per destination port.
In addition, the transmit rate in frames per second for each source
port SHOULD be reported.
6 Overhead 6 Overhead
This section presents methodology relating to the characterization of This section presents methodology relating to the characterization of
the overhead delays associated with explicit operations found in the overhead delays associated with explicit operations found in
multicast environments. multicast environments.
6.1 Group Join Delay 6.1 Group Join Delay
Definition Definition
skipping to change at page 15, line 4 skipping to change at line 727
Corporate Networks", John Wiley & Sons, Inc, 1998. Corporate Networks", John Wiley & Sons, Inc, 1998.
[Ma98] Mandeville, R., "Benchmarking Terminology for LAN Switching [Ma98] Mandeville, R., "Benchmarking Terminology for LAN Switching
Devices", RFC 2285, February 1998. Devices", RFC 2285, February 1998.
[Mt98] Maufer, T. "Deploying IP Multicast in the Enterprise." Prentice- [Mt98] Maufer, T. "Deploying IP Multicast in the Enterprise." Prentice-
Hall, 1998. Hall, 1998.
[Se98] Semeria, C. and Maufer, T. "Introduction to IP Multicast [Se98] Semeria, C. and Maufer, T. "Introduction to IP Multicast
Routing." http://www.3com.com/nsc/501303.html 3Com Corp., 1998. Routing." http://www.3com.com/nsc/501303.html 3Com Corp., 1998.
11
Author's Addresses
Hardev Soor
IXIA
26601 W. Agoura Rd.
Calabasas, CA 91302
USA
Phone: 818 871 1800
EMail: hardev@ixiacom.com
Debra Stopp
IXIA
26601 W. Agoura Rd.
Calabasas, CA 91302
USA
Phone: 818 871 1800
EMail: debby@ixiacom.com
Ralph Daniels
Netcom Systems
948 Loop Road
Clayton, NC 27520
USA
Phone: 919 550 9475
EMail: Ralph_Daniels@NetcomSystems.com
Appendix A: Determining an even distribution
It is important to understand and fully define the distribution of
frames among all multicast and unicast destinations. If the
distribution is not well defined or understood, the throughput and
forwarding metrics are not meaningful.
In a homogeneous environment, a large single burst of multicast
frames may be followed by a large burst of unicast frames. This is a
very different distribution than that of a non-homogeneous
environment, where the multicast and unicast frames are intermingled
throughout the entire transmission.
The recommended distribution is that of the non-homogeneous
environment because it more closely represents a real-world scenario.
The distribution is modeled by calculating the number of multicast
frames per destination port as a burst, then calculating the number
of unicast frames to transmit as a percentage of the total frames
transmitted. The overall effect of the distribution is small bursts
of multicast frames intermingled with small bursts of unicast frames.
12
Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved. This
document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/