![background image](http://html1.mh-extra.com/html/foundry-networks/netiron-m2404c/netiron-m2404c_user-manual_23242731055.webp)
Foundry NetIron M2404C and M2404F Metro Access Switches
Network Administration Tools (Rev. 03)
Response Time Reporter (RTR)
© 2008 Foundry Networks, Inc.
Page 119 of 155
o
File I/O performance metering.
o
E-Mail connectivity.
o
TCP connection set-up time and etc.
•
UDP Echo Response Time is useful for:
•
Real-Time traffic performance monitoring, like Voice over IP, Video over IP and other
applications.
•
Various peer-to-peer real-time applications.
•
ICMP Ping Reply Time is useful for general network diagnostics (for example to inspect full
network connectivity or connectivity between two network nodes.).
Network Service Level Monitoring Objectives
Network Service Level Agreement (SLA) specifies the responsibilities of an IT service provider,
which may be either an internal IT department in some enterprise or an external ISP. Enterprises
expect SLAs to guarantee specific levels of functionality, network bandwidth, QoS, performance,
and uptime in business-critical computing environments.
The network SLA identifies the network performance levels that an internal or an external service
provider guarantees in the course of delivering application services to its customer.
SLA may spell out acceptable data losses and data latency (or data delays), plus bandwidth
provisioning. While a 5% data loss rate is intolerable for the effective operation of real-time
applications such as Voice over IP (VoIP), it is acceptable for less demanding applications. Data
latency is just as critical as data loss in VoIP and multimedia environments in which delays must
not impact end-user performance. Real-time interactive applications require response times of 100
milliseconds (ms) or less.
Different applications using the network services need different Service Level Objectives (SLO).
The main idea behind SLA monitoring is to quantify those SLOs into SA metrics and measured
values, which can be monitored for a period of time.
It is impossible to define SLOs universally. Various QoS, security and tunneling mechanisms use
TCP and UDP specific information to differentiate the network traffic. Moreover, different
applications behave differently on the same network Basic facts such as these dictate the necessity
to define specific SLOs for each (important) application.
Network SLOs may be matched against specific thresholds or monitored over certain periods of
time. The results may be used in statistical calculations in order to identify SLA violations.
Generally, some graphic abilities are required to reflect success or failure to achieve each single
SLO.
Table 28
describes example SLOs to be monitored by the application software.
Table 28: Example SLOs to be Monitored by the Application Software
Request Type
Monitoring Modes to be Implemented
ICMP Echo Ping
Periodically issue ICMP echo requests and measure the delays until
ICMP replies arrive. Aggregate the measurements to enable jitter and
average delay calculations. Use the results to estimate the general
network performance.