170 likes | 401 Views
QoS monitoring. TF-NGN , Schiphol Dec. 17 th , 200 2 Victor Reijs victor.reijs@heanet.ie. Outline. Type of measurements… Scope of measurements… Specification of measurement infrastructure… Black: mandatory. Grey: optional at start. Type of Measurements.
E N D
QoS monitoring TF-NGN, Schiphol Dec. 17th, 2002 Victor Reijs victor.reijs@heanet.ie QoS monitoring
Outline • Type of measurements… • Scope of measurements… • Specification of measurement infrastructure… • Black: mandatory. Grey: optional at start QoS monitoring
Type of Measurements • Active and passive measurements • Network transport diagnostics... • Network service diagnostics... • SLS metric... • Application metric... QoS monitoring
Network transport diagnostics • Basic diagnostic if transport is sound • after every change (hard/software) • min. every day • debugging monitoring • Examples: • connectivity (path) • MTU fragmentation (path) • BER (link) • data-value dependent errors (path) • routing (path) QoS monitoring
Network service diagnostics • Diagnostics to determine if services is sound • after every change (hard/software) • min. every hour • debugging, weather-map, trend monitoring • Examples: • overprovisioning: load link (path) • IP-Premium: queue levels (link), DSCP transparency (path), link load (path) • LBE: DSCP transparency (path) QoS monitoring
SLSmetric • Diagnostics to determine if one-way SLS is met • min. every 5 min • debugging, weather-map, trend monitoring • List: • Available bandwidth (avail-bw) (+/- 10%) • Packet loss (OWPL) (+/- 1-order) • Loss pattern (-) • IP packet delay variation (ipdv) (+/- 1 msec) • Delay (OWD) (+/- 1 msec) QoS monitoring
Application metric • Diagnostics to determine if application is sound • min. every 5 min • debugging, weather-map, trend monitoring • Examples: • MOS for audio and video • performance for GRID QoS monitoring
Scope of measurement • End-to-end (inter domain) • must support this in future • Between domain boundaries (intra domain) • must support this • concatenation of result for end-to-end • Within domain (intra domain) • must support this QoS monitoring
Specification of measurement infrastructure (1) • Flexible measurement platform • for end-users and network managers • different operating systems • Different measurements • active and passive measurements • Upgradeable • support the moving and evolving environment QoS monitoring
Specification of measurement infrastructure (2) • Secure access to infrastructure and data • Multiple network management domains • Trustable and exchangeable results • resource management • standardized protocol/methodology QoS monitoring
NIMI: National Internet Measurement Infrastructure • Code is light-weight and portable • Dynamic (evolving) • Function with minimal human intervention • Secure authentication (PKI) • Modular (can run on different systems): • requesting measurements (MeasurementPOC) • configuring probes (ConfigurationPOC) • making measurements (nimi-daemon) • analyzing results QoS monitoring
Systems in use by HEAnet • RIPE TTM (active) • NetIQ Chariot (active) • NetFlow (passive): Top 50 systems • MRTF with weather map (passive): http://www.hea.net/ • NLANR AMP box (active) • Looking glass QoS monitoring
Communication with others • IMRG: Internet Measurement Research Group https://www1.ietf.org/mailman/listinfo/imrg • IPPM: Internet Protocol Performance Metrics http://www.advanced.org/IPPM/ • NIMI: National Internet Measurement Infrastructure http://www.psc.edu/networking/papers/nimi.html • TF-NGN http://www.dante.net/tf-ngn/D9.7-test_traffic_measurement_tools.pdf QoS monitoring
One-way delay with GPS or NTP? TF-NGN, Schiphol Dec. 17th, 2002 Victor Reijs and Vladimir Smotlacha victor.reijs@heanet.ie QoS monitoring
NTP considerations • Any asymmetric routing between NTP server and client is killer for NTP performance • Maximal error of NTP is one half of RTT server-client • Max. error can be worse as a result of dynamic effects of loopback in NTP process • If network is small (RTT< 3 msec), GPS can only measure one-way delay accurately • Default NTP configuration is optimal for robustness not for accuracy • Most accurate NTP configuration: only one NTP server, low value (from 4 to 6) of maxpoll parameter QoS monitoring
NTP set-up • At least one primary NTP server with GPS for each NREN GPS with PPS signal output can be used In case of long cable: RS-422 output level is preferred • Optimal is one NTP server for each large metropolitan network (maximal RTT server-client is 3 ms) • NTP accuracy better then 0.1 ms can't be reached with standard HW (i.e. normal quartz oscillator inside the box) • A monitoring NTP service is perhaps needed to be able to estimate the max. error. • Vladimir will make a document/presentation on this QoS monitoring