Chariot and IP Multicast

Transcription

1 Chariot and IP Multicast Application Note by John Q. Walker, NetIQ Corporation Contents Emulating IP Multicast Applications...2 Streaming Scripts...3 Modifying the Multimedia Run Options for the Test...6 Setting Up Your Hardware and Software For IP Multicast...6 For More Information...8 Copyright Information...9 NetIQ s Chariot supports extensive testing with IP Multicast. In IP Multicast delivery, an application sends data to a single address, called a multicast group address. The routers in the network decide where to deliver the data based on whether downstream applications are listening on that multicast group address. The benefit of IP Multicast is that it avoids multiple unicast connections to deliver data to multiple receivers. Unlike broadcasting, the data is only sent to destinations where applications are listening and want to receive the data. 1

2 IP Multicast uses UDP or RTP to deliver data from one sender to multiple receivers. IP Multicast testing with Chariot requires NetIQ Performance Endpoints. Any computer designated as Endpoint 1 can send data to a group of multiple Endpoint 2 computers with a single UDP or RTP data stream. The sender does not guarantee delivery of the data to the receivers. However, every multicast receiver in a Chariot test tracks lost datagrams, duplicate and out-of-order datagrams, and, for RTP, the variation in the arrival time of the datagrams called jitter. Most multimedia applications stream data to their receivers, without expecting acknowledgment of delivery. Chariot multimedia support is based on sending a stream of data from Endpoint 1 to one or more Endpoint 2 receivers, without acknowledgments or retransmissions. Data may be sent as fast as possible or at a controlled data rate. This data rate is controlled using the send_data_rate parameter of the SEND command in the application script. You can also vary the file size (that is, the interval between timing records) and the size of each datagram that is sent. In an IP Multicast group, receivers must subscribe to the multicast group prior to receiving data. The multicast group is identified with the IP Multicast address and port. The multicast address specifies the multicast group to which data should be delivered. This class D IP address falls in a specified numeric range. The IP Multicast port identifies one of the possible destinations within a given host computer. Chariot uses the combination of the multicast address and multicast port to uniquely identify a multicast group. In IP Multicast delivery, you can constrain how far an IP Multicast packet is forwarded. Routers use the Time To Live (TTL) value to determine when to stop forwarding packets. TTL is a router hop count, not a time duration. Set the TTL so the sending endpoint can reach all the receiving endpoints in the group. This should be the value used by the sender in the multicast application you are emulating. To emulate a multimedia application, select one of the streaming scripts in Chariot. When you select a streaming script, data is sent in only one direction. Throughput and lost data are calculated by Endpoint 2. Because of the nature of connection-less protocols like UDP and RTP, lost and out-of-order data can occur. This does not cause streaming pairs to fail. The Chariot test results contain information about the data quality, for pairs running streaming scripts. The Multimedia Data tab in the Test window lets you see how much data was lost during the run. Graphs of lost data are associated with this tab, so you can graphically view how much or when the data was lost. You can use the Datagram tab to view the number of lost or out of order datagrams. Emulating IP Multicast Applications Endpoints use the IP Multicast address and port to send data to all members in a multicast group. In tests containing multicast groups, Endpoint 1 acts as the sender and the computers in the role of Endpoint 2 act as the receivers. You can set the TTL used for the IP Multicast packets. You can also change the default timeout used by the Endpoint 2 computers. This timeout simulates the buffering done by receivers of multicast data; after some amount of time, they have to decide that the sender is no longer sending. To emulate an IP Multicast application, first set up a multicast group at the Chariot console. Select the Add Multicast Group menu item from the Edit menu in the Test window. Within a test, you can configure multiple groups to emulate different applications, sending data to multiple sets of addresses. The IP Multicast address and port combination must be unique for each multicast group in a test. Valid IP Multicast addresses are through (these are the class D IP addresses). Chariot does not allow a multicast group address that is not in this range. Some class D addresses are reserved and should be avoided. For example, addresses between and are reserved for routing protocols and other low-level topology discovery or maintenance protocols. Chariot lets you specify 2

3 any IP Multicast address. However, when testing with a reserved IP Multicast address, be aware that other applications, hosts, or routers may be transmitting data to this address. Unexpected test results may occur. We recommend using addresses beginning with or higher. Because UDP and RTP are unreliable protocols, data may be lost. At the end of a test, the Endpoint 2 computers report the number of bytes and datagrams lost during the script. Lost data does not cause a pair to fail while running. Here s a simple example of IP Multicast testing, with one multicast group consisting of three computers (each labeled Endpoint 2, below). Figure 1: An IP Multicast test, with one sender and three multicast receivers. The key flows in the above picture are numbered and described below. 1. A test is created at the Chariot console, and the user presses the Run button. The console sends the setup information to Endpoint 1, using a TCP connection. The setup includes the following: the application script (a streaming script), the specific IP address of each Endpoint 2 in the multicast group, the protocol to use when connecting to Endpoint 2 (UDP or RTP), the Quality of Service (QoS) to use (if any), the multicast group address (a class D IP address) that each Endpoint 2 should use while the test is running. how long to run the test, and how to report results. 2. Endpoint 1 keeps its half of the application script, and forwards the other half to each Endpoint 2 in the multicast group, using a TCP connection. It also sends them the multicast group address on which they should receive while the test is running. When all Endpoint 2 computers have acknowledged they are ready, Endpoint 1 replies to the console on its TCP connection. When all endpoint pairs are ready, the console directs them all to start. 3. Endpoint 1 executes its streaming script as the UDP or RTP sender, with the Endpoint 2 computers receiving the data. Endpoint 1 collects timing records; each Endpoint 2 collects information on lost data. 4. Endpoint 2 computers return information on lost data to Endpoint 1. Endpoint 1 returns this information and timing records to the console, which displays the results. Avoid trying to use a single Endpoint 2 in multiple places in a single multicast group. This includes multiple IP addresses or multiple domain names that actually represent the same computer. The endpoint attempts to bind to the same port, which will result in a UDP Communications Error during the test setup. Streaming Scripts Streaming scripts emulate applications which send and receive multimedia data. Datagrams are sent in one direction only, from Endpoint 1 to Endpoint 2. There is no acknowledgment from Endpoint 2 that data has been received. Chariot streaming scripts have a fixed format; you can't add, move, or delete commands in streaming scripts, although you can change their script variables. Typical multimedia applications use various packet sizes. When emulating such an application, you should account for any header that may be included in the size or the packet. Endpoint multimedia support uses a 9-byte header in each datagram packet sent and UDP uses an 8-byte header. This results in a 17-byte header. For example, to emulate a packet size of 617 bytes, set 3

4 the send_buffer_size script variable to 600 bytes. RTP rides inside the user datagram protocol (UDP) and thus is connectionless. RTP is not part of the TCP/IP protocol stack, so the endpoint software is coded to add and recognize an additional 12-byte header in each UDP datagram. Script Category Cisco IP/TV NetMeeting NetShow Real Audio Voice Over IP Typical multimedia applications send data at a specified rate. All of our scripts now let you control their data rate, by modifying the send_data_rate script variable. Setting an appropriate send_data_rate is especially important for streaming scripts, since they can easily consume all available bandwidth. None of the streaming scripts are shipped with the send_data_rate set to UNLIMITED. We don't recommend the UNLIMITED setting for streaming scripts, except when doing stress testing. Script File Name Script Description Send Data Rate IPTVA.SCR IPTVV.SCR NETMTGA.SCR NETMTGV.SCR Cisco System's IP/TV application, MPEG audio or video streams Emulates sending an audio or video stream using NetMeeting v2.1 over a 100 Mbps Ethernet LAN. 93 kbps 1451 kbps 12 kbps 64 kbps Buffer Size (bytes) NETSHOWU.SCR Emulates the NetShow application kbps 526 REALAUD.SCR REALMED.SCR VOIPS.SCR VoIPG711.SCR VoIPG723a.SCR VoIPG723m.SCR VoIPG729.SCR Emulates Real Audio applications, by RealNetworks: CD streaming and audio-video stream smart Emulates a one-way voice over IP conversation. VoIPs emulates a G.711 codec stream. The RTP_PAYLOAD_TYPE is set to PCMU. PCMU is the U.S. version of G.711 (PCMA is the European version). VoIPG711 also represents a VoIP call using a newer version of the G.711 codec, which uses a larger packet size. The G codec is used by a variety of PC applications, including Netmeeting. VoIPG723a represents a VoIP call that is using the G codec with ACELP compression. VoIPG723m represents a VoIP call that is using the G codec with MPMLG compression. VoIPG729 represents a VoIP call that is using the G.729 codec. This script includes the data traffic only; it does not include any "comfort noise" traffic. Figure 2: These are the streaming scripts currently shipped with Chariot kbps 300 kbps 64 kbps 64 kbps 5.3 kbps 6.3 kbps 8 kbps If one of these streaming scripts doesn t meet your needs, any of them can be easily modified. Also, you can create a new streaming script. Select the Script Editor menu item from the Tools menu on the Main window and then select the New menu item from the File menu. From the New Script 4

5 dialog, select the Streaming script template for the new script. Streaming Performance Another important measurement for streaming applications is the amount of lost data. Lost data is something that applications using a connectionoriented protocol like TCP do not experience. If a TCP application sends data, the underlying protocol stack ensures that the data reaches the receiver. Connection-less protocols, such as UDP, can have data reliability schemes implemented by the application above the protocol. For UDP response time and throughput tests, reliable datagram support ensures that data is dependably transferred. However, there is a class of multimedia applications, such as voice and video, that can tolerate the loss of some datagrams. These applications typically ride on top of UDP. UDP itself does not ensure that the data makes it to the receiver, so the applications must deal with lost data. Why is lost data important? Have you ever tried to watch a movie and seen it freeze before jumping to a different scene? Lost data can mean lost scenes in a video application. Likewise for telephone calls: lost data can cause the speaker s voice to sound unintelligible. How much is too much when it comes to lost data? This varies by application; some real-time applications can tolerate certain amounts of lost data because they buffer data as it is received. Other applications don t tolerate lost data. Typically, lost data is described as bytes lost or the percentage of bytes that were lost. Chariot measures lost data by instructing Endpoint 1 to stream data at a fixed rate. Lost data is data that is not received by the Endpoint 2. The data could be discarded in the network at various routers or it may be discarded by the TCP/IP stack. Endpoint 2 calculates how much data is lost. Endpoint 1 Endpoint Loop for duration Start stopwatch Send N bytes Sleep to control rate End Loop Receive N bytes Stop stopwatch Figure 3: The transaction between the endpoints during a Chariot streaming test. Chariot uses the following equation for calculating the percentage of lost data. L = ((S - R) / S) * 100 where: L = percentage of lost data S = total bytes sent by Endpoint 1 R = total bytes received by Endpoint 2 The test summary shows the amount of data lost in bytes, the percentage of data lost, and the actual throughput at the receiver. In Chariot streaming tests, each Endpoint 2 keeps track of the data that is lost. Endpoint 1 streams data at a fixed rate with no acknowledgment, telling Endpoint 2 how much data has been sent. Endpoint 2 calculates the lost data total and returns it to the Chariot console, via Endpoint 1. Lost data is shown in increments of 0.1%. A considerable percentage of data may be lost in streaming tests. Data loss has several causes. For example, the data rate may be higher than the maximum throughput potential of a network. Packets can be lost due to interference during transmission, or the receiver may not be capable of keeping up with the sender and may drop packets. A network may be congested: if intermediate routers are congested, datagram packets may be discarded. In these cases, check to make sure you ve selected the correct units for your test. Try decreasing the streaming rate or changing the units to see if the results improve. Your network may be configured to give nonstreaming traffic priority over streaming traffic and may discard datagram packets when the two compete for bandwidth. Try running a throughput test using TCP for comparison. If your throughput is unexpectedly low, network congestion is the likely cause. 5

6 Modifying the Multimedia Run Options for the Test Two Chariot Run Options affect how multimedia support behaves at endpoints. These parameters apply to all streaming pairs in a test. The Run Options are: Receive Timeout (in milliseconds) IP Multicast Time To Live Set these parameters to be as similar as possible to the multicast application you are simulating. If you want to determine what those values should be, here are some general guidelines: 1. Receive Timeout is the number of milliseconds the endpoint issuing a RECEIVE command waits before determining that a script has ended. If the data has not been received in this amount of time, endpoints send a notification to the sender that the data was not received. If Endpoint 2 is using Windows 95/98/Me or NT/2000, the minimum receive timeout value is 500 milliseconds. If you set this number too low and the transmission encounters normal network delays, the receiver may time out while the data is still transmitting. If you set this number too high, the receiver may spend unnecessary time waiting for a transmission that has failed. Receive Timeout is used for both streaming pairs and multicast groups. This value is configured on the Datagram tab of the Run Options notebook. 2. IP Multicast Time To Live (TTL) controls the forwarding of IP Multicast packets. Set the TTL value based on how far you want the data forwarded. Expect to do some experimentation to find the best combination of variable settings. A good rule is to set the TTL to one more than the maximum number of routers between endpoints. This field defaults to 1. A value of 1 means that the packet does not leave the sender s local subnet. If you want to route the packet across a router, you must set the value of this field to at least 2. Chariot message CHR0216 is returned at the console when the TTL is too small. This message is returned long after the test starts after Endpoint 2 times out since TCP with a different TTL is used to set up the test, and the TCP connection is successful. We have found that for endpoints on Windows 95/98/Me or NT/2000, a TTL value of 0 lets the packet leave the local host. If you run a loopback test with one computer, you may impact the performance of your network, as the packets are broadcast on the local subnet. Setting Up Your Hardware and Software For IP Multicast Before you run a test containing multicast groups, you must do the following to prepare your hardware and software for IP Multicast. 6

7 Operating System Compaq Tru64 UNIX Version with IP Multicast support v4.0b Version with IGMP v2 support v4.0b FreeBSD v HP-UX v10.10 v10.10 IBM AIX v4.1 v4.21 IBM OS/2 Warp 4 with TCP v4.1 Warp 4 with TCP v4.1 IBM MVS OS/390 v2r6 OS/390 v2r6 Linux kernel v kernel v Windows 3.x Windows 95/98/Me Windows NT/2000 Novell NetWare Chameleon v7.0 Win98, WinMe, or Win95 with WinSock 2 NT 4.0 none v4.x v4.11 SCO UnixWare v7.0 v7.0 SGI IRIX v6.2 v6.2 Sun Solaris v2.4 v2.6 Windows 98 NT 4.0 with SP4 To test with IP Multicast, NetIQ Performance Endpoint software needs to be running on the operating system. Endpoints for these operating systems can be downloaded for free at: Configure Your Router to Enable IP Multicast Support Many of today s routers have IP Multicast support built in. However, this support is not automatically enabled. To run tests containing multicast groups across a router, you must first configure the IP Multicast support, which enables IP Multicast data to be forwarded by your router. (You obviously do not need to perform this step if you are running a test containing multicast groups without a router.) For information on how to enable and configure your routers IP Multicast support, refer to their documentation. Verify the Router Operating System is IP Multicast Enabled Each router has an embedded operating system. Verify that this operating system is enabled for IP Multicast support. See the documentation for your router for more information. The router should be updated with the latest ROM, EEPROM, BIOS, or microcode revision level. Verify Your Routers Have Enough RAM Providing support for IP Multicast routing increases the amount of RAM required by a router. Routers maintain additional routing tables (discussed below) to decide how to forward IP Multicast packets. See the documentation for your routers to determine the amount of RAM required for IP Multicast applications. If necessary, add additional RAM before running tests containing multicast groups. Make Decisions on Routing Table Algorithms There are three families of IP Multicast routing algorithms: DVMRP, M-OSPF, and PIM. Your network administrator must decide which routing algorithms to implement for the routers in your network. This is important so that your routers can communicate IP Multicast routing information with each other. DVMRP The Distance-Vector Multicast Routing Protocol (DVMRP) forwards packets based on the source of the subnetwork s location. This is the only algorithm that has its own unicast routing protocol. 7

8 M-OSPF The Multicast Extensions to Open Shortest Path First (MOSPF) uses Intra-area routing inside an OSPF. This algorithm uses sourcebased trees. PIM There are three Protocol-Independent Multicast routing algorithms: PIM-DM, PIM-SM, PIM-SD. Protocol-Independent Multicast Dense Mode (PIM-DM) communicates IP Multicast information to groups that a located in a small geographic area. Protocol-Independent Multicast Sparse Mode (PIM-SM) communicates IP Multicast information to sparsely distributed groups. One of the goals of this algorithm is to limit traffic by only providing data to routers interested in the information. Protocol-Independent Multicast Sparse- Dense Mode (PIM-SD) combines the best attributes of PIM s sparse and dense modes. This should probably be your first choice in multicast routing algorithms, given a choice. For More Information For thorough information on IP Multicast (including books, tutorials, papers, and lots of helpful URLs), visit and click on Multimedia/VoIP. For more information on Chariot, visit and press the Network Performance Management button. For those using Cisco routers, there s excellent information on Multicast deployment at: There s an IP Multicast FAQ at 8

9 Copyright Information NetIQ Corporation provides this document as is without warranty of any kind, either express or implied, including, but not limited to, the implied warranties of merchantability or fitness for a particular purpose. Some states do not allow disclaimers of express or implied warranties in certain transactions; therefore, this statement may not apply to you. This document and the software described in this document are furnished under a license agreement or a non-disclosure agreement and may be used only in accordance with the terms of the agreement. This document may not be lent, sold, or given away without the written permission of NetIQ Corporation. No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, or otherwise, with the prior written consent of NetIQ Corporation. Companies, names, and data used in this document are fictitious unless otherwise noted. This document could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein. These changes may be incorporated in new editions of the document. NetIQ Corporation may make improvements in and/or changes to the products described in this document at any time NetIQ Corporation, all rights reserved. U.S. Government Restricted Rights: Use, duplication, or disclosure by the Government is subject to the restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause of the DFARs and FAR (c) and any successor rules or regulations. AppManager, the AppManager logo, AppAnalyzer, Knowledge Scripts, Work Smarter, NetIQ Partner Network, the NetIQ Partner Network logo, Chariot, Pegasus, Qcheck, OnePoint, the OnePoint logo, OnePoint Directory Administrator, OnePoint Resource Administrator, OnePoint Exchange Administrator, OnePoint Domain Migration Administrator, OnePoint Operations Manager, OnePoint File Administrator, OnePoint Event Manager, Enterprise Administrator, Knowledge Pack, ActiveKnowledge, ActiveAgent, ActiveEngine, Mission Critical Software, the Mission Critical Software logo, Ganymede, Ganymede Software, the Ganymede logo, NetIQ, and the NetIQ logo are trademarks or registered trademarks of NetIQ Corporation or its subsidiaries in the United States and other jurisdictions. All other company and product names mentioned are used only for identification purposes and may be trademarks or registered trademarks of their respective companies. 9