TFNGN, Schiphol

1
QoS monitoring

• TF-NGN, Schiphol
• Dec. 17th, 2002
• Victor Reijs
• victor.reijs_at_heanet.ie

2
Outline

• Type of measurements
• Scope of measurements
• Specification of measurement infrastructure
• Black mandatory. Grey optional at start

3
Type of Measurements

• Active and passive measurements
• Network transport diagnostics...
• Network service diagnostics...
• SLS metric...
• Application metric...

4
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)

5
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)

6
SLS metric

• 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)

7
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

8
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

9
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

10
Specification of measurement infrastructure (2)

• Secure access to infrastructure and data
• Multiple network management domains
• Trustable and exchangeable results
• resource management
• standardized protocol/methodology

11
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

12
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

13
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_meas
  urement_tools.pdf

14
One-way delay with GPS or NTP?

• TF-NGN, Schiphol
• Dec. 17th, 2002
• Victor Reijs and Vladimir Smotlacha
• victor.reijs_at_heanet.ie

15
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 (RTTlt 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

16
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