path. La mayoría de los routers modernos soportan esta característica que aunque esta implementación presente otras ineficiencias, resuelve el problema del reordenamiento de paquetes.
El reordenamiento de paquetes es un problema “silencioso”, dado que la mayoría de los routers contabilizan pérdidas de paquetes y puede mostrar este tipo de información a los operadores, pero el reordenamiento de paquetes es invisible para estos dispositivos y no dejan trace alguno, y así los operadores de red no pueden identificar la potencial causa de degradación del throughput del tipo TCP. El reordenamiento de paquetes combinado con un cierto nivel de pérdidas de paquetes, originen múltiples invocaciones del mecanismo de “fast recovery” [37] de la ventana de TCP, lo que lleva a una cierta pérdida de la utilización del enlace y del throughput de las aplicaciones debido a que cualquier paquete fuera de orden que arriba al receptor hace que el mismo dispare un ACK duplicado en el cual el receptor repite al ACK del último segmento recibido fuera de orden. Cualquier otro segmento fuera de orden causará otro ACK duplicado. El emisor sin embargo considera que si recibe tres ACKs duplicados es señal que el segmento se perdió y dispara la retransmisión del segmento perdido. Las retransmisiones ocurren sin esperar un timeout, esto se conoce como “fast retransmit” [38]. Una vez que las retransmisiones toman lugar, el emisor entra en la fase de “fast recovery”. Todo esto hace que el throughput de las aplicaciones TCP disminuya.
En el caso de tráfico UDP con un mecanismo de control de congestión como se verá más adelante, el reordenamiento de paquetes es visto como pérdidas de paquetes y esto disminuye el throughput dado que éste es función inversa de las mismas.
5.7.Medición de ancho de banda, delay, jitter y pérdida de paquetes
Para realizar experiencias con aplicaciones que requieren grandes anchos de banda y que pueden tener consecuencias sobre otros flujos simultáneos, se deben usar herramientas para medir el ancho de banda extremo a extremo.
Una de las herramientas que más se usa se llama Iperf [39] desarrollada por la Universidad de Illinois de EE.UU. Iperf fue desarrollada como una moderna herramienta para medir la performance de ancho de banda TCP y
UDP. Por ejemplo esta herramienta se usó para medir el ancho de banda con paquetes UDP en una experiencia de transmisión de HDTV sin comprimir sobre un enlace ultra rápido de la red SuperNet del programa Next Generation Internet entre la ciudades estadounidenses de Arlington y Pittsburg.
Es una herramienta para medir el máximo ancho de banda TCP permitiendo el tuning de varios parámetros y las características UDP. Mide también con modalidad multicast y paquetes IPv6. Iperf reporta ancho de banda, delay, jitter y pérdida de paquetes. Corre sobre sistemas operativos Unix y Windows, y necesita la instalación de un servidor y un cliente. El servidor se instala en un extremo del enlace y el cliente en el otro.
En el caso de UDP –usado preferentemente por las aplicaciones que necesitan tiempo real- crea un stream a una velocidad (bit rate) constante. Uno puede ajustar el tamaño de datagrama según el utilizado por la aplicación. El server detecta pérdida de datagramas por el ID asignado a cada datagrama. Usualmente un datagrama UDP se transmite en diversos paquetes IP. Por lo tanto, perdiendo un único datagrama IP se perderá el datagrama entero. Por lo tanto, para medir pérdida de paquetes en lugar de pérdida de datagramas, hay que hacer el tamaño del datagrama lo suficientemente pequeño para que entre en un paquete IP. También da un reporte de los datagramas fuera de secuencia o reordenados.
El cálculo de jitter en UDP, es computado en forma permanente en el server, como lo especifica RTP [40]. El cliente graba un timestamp de 64 bit sec/microsec en el paquete. El server computa el tiempo de tránsito relativo como la diferencia entre el tiempo de recepción del server y el tiempo de envío del cliente. Los relojes del server y cliente no necesitan estar sincronizados, cualquier diferencia es restada del cálculo del jitter. El jitter es el término medio alisado de la diferencias entre tiempos de tránsito consecutivos.
Aquí va un ejemplo:
node2> iperf -s -u -i 1
--- --
Server listening on UDP port 5001 Receiving 1470 byte datagrams
UDP buffer size: 60.0 KByte (default)
--- --
[ 4] local <IP Addr node2> port 5001 connected with <IP Addr node1> port 9726
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.0- 1.0 sec 1.3 MBytes 10.0 Mbits/sec 0.209 ms 1/ 894 (0.11%)
[ 4] 1.0- 2.0 sec 1.3 MBytes 10.0 Mbits/sec 0.221 ms 0/ 892 (0%)
[ 4] 2.0- 3.0 sec 1.3 MBytes 10.0 Mbits/sec 0.277 ms 0/ 892 (0%)
[ 4] 3.0- 4.0 sec 1.3 MBytes 10.0 Mbits/sec 0.359 ms 0/ 893 (0%)
[ 4] 4.0- 5.0 sec 1.3 MBytes 10.0 Mbits/sec 0.251 ms 0/ 892 (0%)
[ 4] 5.0- 6.0 sec 1.3 MBytes 10.0 Mbits/sec 0.215 ms 0/ 892 (0%)
[ 4] 6.0- 7.0 sec 1.3 MBytes 10.0 Mbits/sec 0.325 ms 0/ 892 (0%)
[ 4] 7.0- 8.0 sec 1.3 MBytes 10.0 Mbits/sec 0.254 ms 0/ 892 (0%)
[ 4] 8.0- 9.0 sec 1.3 MBytes 10.0 Mbits/sec 0.282 ms 0/ 892 (0%)
[ 4] 0.0-10.0 sec 12.5 MBytes 10.0 Mbits/sec 0.243 ms 1/ 8922 (0.011%)
node1> iperf -c node2 -u -b 10m
--- --
Client connecting to node2, UDP port 5001 Sending 1470 byte datagrams
UDP buffer size: 60.0 KByte (default)
--- --
[ 3] local <IP Addr node1> port 9726 connected with <IP Addr node2> port 5001
[ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 12.5 MBytes 10.0 Mbits/sec [ 3] Sent 8922 datagrams
En el ejemplo siguiente se nota un jitter más grande debido al reensamble de datagramas cuando se usan datagramas mayores a 32 KBytes, los que se dividen en 23 paquetes de 1500 Bytes. La mayor pérdida de datagramas que se ve aquí puede ser debida al “burstiness” (característica de ráfaga) del tráfico, el cual es de 23 paquetes back-to-back y luego una larga pausa, más bien que a paquetes individuales espaciados uniformemente.
node2> iperf -s -u -l 32k -w 128k -i 1
--- --
Server listening on UDP port 5001 Receiving 32768 byte datagrams UDP buffer size: 128 KByte
--- --
[ 3] local <IP Addr node2> port 5001 connected with <IP Addr node1> port 11303
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 3] 0.0- 1.0 sec 1.3 MBytes 10.0 Mbits/sec 0.430 ms 0/ 41 (0%)
[ 3] 1.0- 2.0 sec 1.1 MBytes 8.5 Mbits/sec 5.996 ms 6/ 40 (15%)
[ 3] 2.0- 3.0 sec 1.2 MBytes 9.7 Mbits/sec 0.796 ms 1/ 40 (2.5%)
[ 3] 3.0- 4.0 sec 1.2 MBytes 10.0 Mbits/sec 0.403 ms 0/ 40 (0%)
[ 3] 4.0- 5.0 sec 1.2 MBytes 10.0 Mbits/sec 0.448 ms 0/ 40 (0%)
[ 3] 5.0- 6.0 sec 1.2 MBytes 10.0 Mbits/sec 0.464 ms 0/ 40 (0%)
[ 3] 6.0- 7.0 sec 1.2 MBytes 10.0 Mbits/sec 0.442 ms 0/ 40 (0%)
[ 3] 7.0- 8.0 sec 1.2 MBytes 10.0 Mbits/sec 0.342 ms 0/ 40 (0%)
[ 3] 8.0- 9.0 sec 1.2 MBytes 10.0 Mbits/sec 0.431 ms 0/ 40 (0%)
[ 3] 9.0-10.0 sec 1.2 MBytes 10.0 Mbits/sec 0.407 ms 0/ 40 (0%)
[ 3] 0.0-10.0 sec 12.3 MBytes 9.8 Mbits/sec 0.407 ms 7/ 401 (1.7%)
node1> iperf -c node2 -b 10m -l 32k -w 128k
--- --
Client connecting to node2, UDP port 5001 Sending 32768 byte datagrams
UDP buffer size: 128 KByte
--- --
[ 3] local <IP Addr node2> port 11303 connected with <IP Addr node1> port 5001
[ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 12.5 MBytes 10.0 Mbits/sec [ 3] Sent 401 datagrams
Aquí vale la pena tener en cuenta que en el ejemplo anterior se mide la performance del ancho de banda con datagramas UDP de 32 KB pero transportados con paquetes IP de 1500 Bytes, no con Jumbo Frames.
6.Streaming de multimedia sobre IP