May 1999
Gigabit Ethernet Gets Real (Time)
BY PAUL MALLINDER
Five years ago, the major design consideration for IP networks was to provide adequate
bandwidth to support anticipated future applications. Ethernet networks were evolving to
10/100 networks supporting Internet Web access, and real-time applications involving
intranets or extranets were a vision of the future. Today, gigabit Ethernet is migrating
into existing 10/100 networks, and new applications requiring specified Quality of Service
(QoS) will be deployed on these hybrid technology networks. The emerging real-time
applications will be the killer apps that drive network redesign and expansion, requiring
design considerations to include not just throughput, but also latency and jitter.
Examples of "killer apps" include RealAudio and RealVideo, Internet telephony,
and bandwidth busters such as push technology, Webcasting, and video servers. As new
applications come into vogue, experientially measuring their impact within the hybrid
network prior to full deployment is critical.
GIGABIT NETWORK MIGRATION
The increased demand for raw throughput on IP-based networks has resulted in new physical
layer standards such as gigabit Ethernet and new infrastructure equipment such as Layer 3
switches capable of wire-speed IP routing. Gigabit Ethernet is first being deployed as a
backbone technology migrating from 10/100 based networks and then to the desktop. This
will require upgrades to switches and servers on the network in the form of
modules/software, NICs, and possibly extra processors/operating systems or new switches.
Unknown factors - such as the degree to which the existing desktop will utilize gigabit
Ethernet and the desktop demand for new applications requiring stringent policing on QoS
parameters such as latency, jitter, and throughput - require that the hybrid network run
at optimum functionality and performance.
It is critical to measure and record a performance baseline for the current network
prior to any network upgrading. This reference baseline is needed to quantify the success
of the network upgrade. Performance analysis is achieved by generating wire-speed traffic
and, at a minimum, measuring throughput, latency, and jitter on a representative portion
of the network. The wire-speed traffic generation and measurement is accomplished by
removing the actual physical client and server port connections from the network and
replacing them with traffic generation and analyzing ports.
In order to evaluate traffic generation test equipment for gigabit Ethernet, basic
traffic profile requirements need to be defined.
TRADITIONAL VS. REAL-TIME APPLICATIONS
FTP, Telnet, and Web browsing are examples of traditional applications. They do not
tolerate packet loss, are not bandwidth eaters, and latency and jitter are not an issue.
When a user is connected to a Web site over the Internet, waiting patiently for the page
to be updated is tolerated, to a certain extent.
Real-time applications demand certain key traffic parameters to perform effectively.
These applications are bandwidth intensive, but they can compensate for packet loss. For
example, streaming video being sent from a sever to a client often experiences packet
loss, but the client can detect the loss and fill in the gaps.
A fundamental problem with using an IP network for media transmission is variable
latency/jitter and uneven rates of packet transmission. If too many routers and bridges
are encountered during transmission, they may produce delays. These conditions can affect
VoIP phone calls, video, and whiteboard actions. Most people can tolerate a picture or
screen display that freezes momentarily, but the ears are particularly unforgiving of
audio delay and distortion.
RealAudio and RealVideo applications allow either buffered mode or streaming mode
operation. Streaming mode is extremely sensitive to network congestion. Buffered mode
loads data from the server to the client and then plays the audio/video in the client
environment rather than across the network. Servers dynamically send lower bit streams
followed by higher bit streams when the congestion clears.
With Internet telephony, whether it's phone-to-phone, phone-to-PC, or PC-to-phone,
voice packets can travel a myriad of different ways over the PSTN/PBXs, through telephony
gateways, and over the Internet/intranet before reaching their final destination.
Push technology, Webcasting, and video servers are characterized as bandwidth busters.
They have real appeal for end users and are killer applications driving the requirement
for higher bandwidth. Most network managers ensure that these types of applications never
make it beyond the enterprise firewall, as they cause havoc with network overload.
Deterministic Traffic Profiles
There are discernable patterns crossing these applications for which we can create traffic
profiles. While these patterns will rarely be repeatable, there are determinants to be
looked at (e.g., packet size; bandwidth, latency, jitter; bursty vs. non-bursty) that
drive the feasibility of introducing new applications into the network infrastructure. The
nature of the application will dictate what the nature (in respect to traffic patterns) of
these determinants should be. For example, if we were looking at a real-time voice
application, we would expect the following traffic patterns and determinants:
Packets: small packets not large packets.
Latency: small delay not large delay.
Jitter: small jitter rate not large jitter rate.
Regularity: bursty traffic not non-bursty traffic.
It is both the deterministic and actual application traffic patterns that determine
requirements for the experiential performance analysis and testing.
Look for general deterministic traffic patterns in packet size (smaller packets - e.g.,
VoIP services - require smaller packet size to reduce latency), protocol, application
(dominant), bandwidth, latency, and jitter.
WHAT TO LOOK FOR IN TESTING TOOLS
To determine the optimal traffic generation test equipment for analyzing these
deterministic patterns within a hybrid network, first look at packet generation. This
requires total flexibility, as all aspects of a packet need to be configured: frame size,
preamble size, source and destination MAC, IP header, correct and erroneous checksums,
alignment and dribble errors. Programmable data generators should be able to be inserted
into the frame that allows incrementing, decrementing, or randomization at particular
offsets. Time stamp generation and insertion into the frame at packet generation allows
latency measurements to be collected.
Next, shaping traffic on a particular ingress point to a network is necessary to
generate profiles. Streams allow the number of packets per burst and bursts per stream to
be configured. The gaps between packet (IPG), bursts (IBG), and streams (ISG) must be
individually specified to fully profile the traffic for generation. Complex patterns of
data transmission need to be defined as continuous packet generation or continuous burst
within a stream. Interrupt streams, upon user-specified triggers or events, must be able
to temporarily pause traffic, transmit alternate streams, and then continue the original
data flow.
Capturing and recording real-time statistics for future number crunching is essential.
Each ingress or egress point needs to accumulate statistics in real time, including the
number and rate of frames and bytes sent and received as well as the numbers and rates of
fragments, undersized packets, and alignment errors. In addition, there must be a
capability for generating and measuring QoS traffic for 802.1p,q and IP TOS. Custom
statistics should be configurable on source and destination MAC and/or IP address, data
pattern contents, and error conditions.
For analyzing results, it is critical that sufficient data is captured at the ingress
and egress points of the network. Look for a comprehensive set of triggers and filters
based on source and/or destination MAC and/or IP addresses, data pattern and error
conditions. A nice optional extra is to have decodes for at least IP, UDP, ARP, TCP, and
IGMP.
Another crucial issue is generating actual traffic profiles that are captured within
the network environment. The traffic can be saved and played back at up to wire-speed
through a traffic generation engine. This engine must be implemented in RAM within the
test equipment. The amount of RAM determines the different number of frames that can
actually be transmitted. To transmit 40,000 different gigabit frames would require 4 MB of
RAM. There is a trend to capture actual traffic profiles on one piece of test equipment
and play the data back into the network on a different test device. This would require a
common file format allowing the import and export of such files between the two test
devices.
With increased demand for bandwidth in all networks, the introduction of gigabit
Ethernet is pretty much a foregone conclusion. As mentioned earlier, real-time
applications will be the driving force behind network redesign and expansion. The
challenge for network managers is to support the migration from their existing network to
a gigabit Ethernet, and to gain the benefits of these bandwidth-hungry real-time
applications, without negatively affecting network performance. Testing these
applications, and the effect they have on the network, before they are deployed is
critical to ensuring a smooth, beneficial migration to gigabit Ethernet.
Paul Mallinder is director of Marketing for IXIA Communications, Inc. IXIA is a
leading provider of powerful platforms for testing and verifying today's advanced LAN and
WAN networking equipment. For more information, call IXIA at 818-871-1800, or visit the
company's Web site at www.ixiacom.com.
|
Internet Telephony Magazine
Click here to read latest issue
CUSTOMER 
Cloud Computing Magazine
Click here to read latest issue
IoT EVOLUTION MAGAZINE
