1 nsrc@APRICOT 2009 Manila, Philippines Performance Analysis Network Management Workshop APRICOT 2009 18 February 2009 Hervey Allen Original Materials in Spanish by Carlos Vicente, University of Oregon Network Services

2 nsrc@APRICOT 2009 Manila, Philippines Contents Planning performance management Metrics Network Systems Services Measurement examples

3 nsrc@APRICOT 2009 Manila, Philippines Planning What's the intention? Baselining, Troubleshooting, growth Defend yourself from accusations Who is the information for? Administration, NOC, customers How to structure and present the information Reach: Can I measure everything? Impact on devices (measurements and measuring) Balance between amount of information and time to get it

4 nsrc@APRICOT 2009 Manila, Philippines Metrics Network performance metrics Channel capacity, effective and nominal Channel utilization Delay and jitter Packet loss and errors System performance metrics Availability Memory, Utilization CPU, load, iowait, etc. Service performance metrics

5 nsrc@APRICOT 2009 Manila, Philippines Common network performance measurements Relative to traffic:  Bits per second  Packets per second  Unicast vs. no-unicast packets  Errors  Dropped packets  Flows per second  Round trip time (RTT)  Jitter (variation between packet rtt) jitter is the variation in the time between packets arrivingpacket

6 nsrc@APRICOT 2009 Manila, Philippines Nominal channel capacity The maximun number of bits that can be transmitted for a unit of time (eg: bits per second) Depends on:  Bandwidth of the physical medium Cable Electromagnetic waves  Processing capacity for each transmission element  Efficiency of algorithms in use to access medium  Channel encoding and compression

7 nsrc@APRICOT 2009 Manila, Philippines Effective channel capacity Always a fractoin of the nominal channel capacity Dependent on: Additional overhead of protocols in each layer Device limitations on both ends Flow control algorithm efficiency, etc. For example: TCP

8 nsrc@APRICOT 2009 Manila, Philippines What fraction of the nominal channel capacity is actually in use Important!  Future planning What utilization growth rate am I seeing? For when should I plan on buying additional capacity? Where should I invest for my updates?  Problem resolution Where are my bottlenecks, etc. Channel utilization

9 nsrc@APRICOT 2009 Manila, Philippines 95 th Percentile The smallest value that is larger than 95% of the values in a given sample This means that 95% of the time the channel utilization is equal to or less than this value  Or rather, the peaks are discarded from consideration Why is this important in networks?  Gives you an idea of the standard, sustained channel utilization.  ISPs use this measure to bill customers with “larger” connections.

10 nsrc@APRICOT 2009 Manila, Philippines 95 th Percentile

11 nsrc@APRICOT 2009 Manila, Philippines bps vs. pps

12 nsrc@APRICOT 2009 Manila, Philippines End-to-end delay The time required to transmit a packet through its entire trajectory  Created by an application, handed over to the OS, passed to a network card (NIC), encoded, transmitted over a physical medium (copper, fibre, air), received by an intermediate device (switch, router), analyzed, retransmitted over another medium, etc.  The most common measurement uses ping for total round-trip-time (RTT).

13 nsrc@APRICOT 2009 Manila, Philippines Historical measurement of delay

14 nsrc@APRICOT 2009 Manila, Philippines Types of Delay Causes of end-to-end delay Processor delays Buffer delays Transmission delays Propagation delays

15 nsrc@APRICOT 2009 Manila, Philippines Processing delay Required time to analyze a packet header and decide where to send the packet (eg. a routing decision)  Inside a router this depends on the number of entries in the routing table, the implementation of data structures, hardware in use, etc. This can include error verification

16 nsrc@APRICOT 2009 Manila, Philippines Retardo de Colas Tiempo en que el paquete espera en un búfer hasta ser transmitido El número de paquetes esperando en cola dependerá de la intensidad y la naturaleza del tráfico Los algoritmos de colas en los enrutadores intentan adaptar estos retardos a ciertas preferencias, o imponer un uso equitativo

17 nsrc@APRICOT 2009 Manila, Philippines Retardo de Transmisión El tiempo requerido para empujar todos los bits de un paquete a través del medio de transmisión Para R=Tasa de bits, L=Longitud del paquete, d = delay o retardo: d = L/R Por ejemplo, para transmitir 1024 bits utilizando Fast Ethernet (100 Mbps): d = 1024/1x10e8 = 10.24 micro segundos

18 nsrc@APRICOT 2009 Manila, Philippines Una vez que el bit es 'empujado' en el medio, el tiempo transcurrido en su propagación hasta el final del trayecto físico La velocidad de propagación del enlace depende más que nada de la distancia medio físico  Cercano a la velocidad de la luz en la mayoría de los casos Para d = distancia, s = velocidad de propagación Dp = d/s Retardo de Propagación

19 nsrc@APRICOT 2009 Manila, Philippines Transmisión vs. Propagación Puede ser confuso al principio Considerar un ejemplo:  Dos enlaces de 100 Mbps. Fibra óptica de 1 Km Via Satélite, con una distancia de 30Km entre base y satélite  Para dos paquetes del mismo tamaño, cuál tiene mayor retardo de transmisión? Y propagación?

20 nsrc@APRICOT 2009 Manila, Philippines Ocurren por el hecho de que las colas (búfers) no son infinitas  Cuando un paquete llega a una cola y ésta está llena, el paquete se descarta.  La pérdida de paquetes, si ha de ser corregida, se resuelve en capas superiores (transporte o aplicación)  La corrección de pérdidas, usando retransmisión, puede causar aún más congestión si no se ejerce algún tipo de control Pérdida de paquetes

21 nsrc@APRICOT 2009 Manila, Philippines Jitter

22 nsrc@APRICOT 2009 Manila, Philippines Control de Flujo y Congestión Limitar la tasa de envío porque el receptor no puede procesar los paquetes a la misma velocidad que los recibe Limitar la tasa de envío del emisor porque existen pérdidas y retardos en el trayecto

23 nsrc@APRICOT 2009 Manila, Philippines Controles en TCP IP implementa un servicio no-orientado a conexión  No existe ningún mecanismo en IP que ataque las causas de la pérdida de paquetes TCP implementa control de flujo y congestión  En los extremos, porque los nodos intermedios en la capa de red no hablan TCP

24 nsrc@APRICOT 2009 Manila, Philippines Flujo vs. Congestión en TCP Flujo: controlado por los tamaños de ventana (RcvWindow) enviados por el receptor Congestión: controlado por el valor de ventana de congestión (CongWin)  Mantenido independientemente por el emisor  Varía de acuerdo a la detección de paquetes perdidos Timeout o la recepción de tres ACKs repetidos  Comportamientos: Incremento aditivo / Decremento multiplicativo (AIMD) Comienzo lento (Slow Start) Reacción a eventos de timeout

25 nsrc@APRICOT 2009 Manila, Philippines Diferentes algoritmos de Control de Congestión en TCP

26 nsrc@APRICOT 2009 Manila, Philippines Métricas para sistemas Disponibilidad En sistemas Unix/Linux: Uso del CPU Kernel, System, User, IOwait Uso de la Memoria Real y Virtual Carga (load)

27 nsrc@APRICOT 2009 Manila, Philippines Disponibilidad

28 nsrc@APRICOT 2009 Manila, Philippines Uso del CPU

29 nsrc@APRICOT 2009 Manila, Philippines Memoria

30 nsrc@APRICOT 2009 Manila, Philippines Carga (load)

31 nsrc@APRICOT 2009 Manila, Philippines Métricas de Servicios La clave está en elegir las métricas más importantes para cada servicio Preguntarse: Cómo se percibe la degradación del servicio? Tiempo de espera? Disponibilidad? Cómo justifico mantener el servicio? Quién lo está utilizando? Con qué frecuencia? Valor económico?

32 nsrc@APRICOT 2009 Manila, Philippines Utilización de servidor web

33 nsrc@APRICOT 2009 Manila, Philippines Tiempo de respuesta (servidor web)

34 nsrc@APRICOT 2009 Manila, Philippines Tiempo de Respuesta (servidor DNS)

35 nsrc@APRICOT 2009 Manila, Philippines Métricas de DNS

36 nsrc@APRICOT 2009 Manila, Philippines Métricas de DNS

37 nsrc@APRICOT 2009 Manila, Philippines Métricas de Servidor de Correo Contadores por mailer (local, esmtp, etc.) Número de mensajes recibidos/enviados Número de bytes recibidos/enviados Número de mensajes denegados Número de mensajes descartados Muy importate: Número de mensajes en cola

38 nsrc@APRICOT 2009 Manila, Philippines Estadísticas de Sendmail

39 nsrc@APRICOT 2009 Manila, Philippines Métricas de Web Proxy Número de peticiones por segundo Peticiones servidas localmente vs. las re-enviadas Diversidad de los destinos web Eficiencia de nuestro proxy Número de elementos almacenados en memoria vs. disco

40 nsrc@APRICOT 2009 Manila, Philippines Estadísticas de Squid

41 nsrc@APRICOT 2009 Manila, Philippines Estadísticas de DHCP