Determine las latencias asimétricas en una red

Question

Imagine que tiene muchos servidores en clúster, en muchos hosts, en un entorno de red heterogéneo, de modo que las conexiones entre servidores pueden tener latencias y ancho de banda enormemente variables. Desea construir un mapa de las conexiones entre servidores mediante la transferencia de datos entre ellos.

Por supuesto, este mapa puede volverse obsoleto a medida que cambia la topología de la red, pero dejemos de lado esas complejidades por el momento y supongamos que la red es relativamente estática.

Dadas las latencias entre los nodos en este gráfico de host, calcular el ancho de banda es un ejercicio de temporización relativo simple. Sin embargo, tengo más dificultades con las latencias. Para obtener el tiempo de ida y vuelta, es una simple cuestión de cronometrar un ping de ida y vuelta desde el host local a un host remoto; ambos eventos de temporización (inicio, detención) ocurren en el host local.

¿Qué sucede si quiero tiempos unidireccionales bajo la suposición de que la latencia no es igual en ambas direcciones? Suponiendo que los relojes en los diversos hosts no están precisamente sincronizados (al menos, que su error es de la misma magnitud que las latencias involucradas), ¿cómo puedo calcular la latencia de un solo sentido?

En una pregunta relacionada, ¿esta latencia asimétrica (donde un enlace es más rápido en la dirección que el otro) es común en la práctica? ¿Por qué razones/configuraciones de hardware? Ciertamente soy consciente de los escenarios asimétricos de ancho de banda, especialmente en los enlaces de consumidores de última milla como DSL y Cable, pero no estoy tan seguro de la latencia.

Agregado: Después de considerar el comentario a continuación, la segunda parte de la pregunta probablemente sea mejor en serverfault.

Answer 1

Por lo que yo sé, las latencias asimétricas, especialmente las asimetrías de "última milla", no se pueden determinar automáticamente, porque cualquier protocolo de sincronización de tiempo de red se ve igualmente afectado por la misma asimetría, por lo que no tiene sentido de referencia para evaluar la asimetría.

Si cada punto extremo tuviera, por ejemplo, su propio reloj GPS, entonces tendría un punto de referencia para trabajar.

En Fast Measurement of LogP Parameters for Message Passing Platforms, los autores señalan que la medición de latencia requiere sincronización del reloj externa al sistema que se está midiendo. (Énfasis en negrita, cursiva en texto original.)

latencia asimétrica sólo puede medirse mediante el envío de un mensaje con una marca de tiempo t _s, y dejando que el receptor derivar la latencia de t _r - t _s, donde t r es el tiempo de recepción. Este requiere la sincronización del reloj entre el emisor y el receptor. Sin sincronización de reloj externa (como el uso de receptores GPS o software especializado como el red de protocolo de tiempo de, NTP), los relojes sólo pueden estar sincronizados hasta una granularidad del tiempo de ida y vuelta entre dos anfitriones [10], que es inútil para medir la latencia de la red.

Sin algoritmo basado en red (como NTP) eliminará los problemas de enlaces de última milla, sin embargo, ya que cada entrada al algoritmo será en sí misma de manera uniforme sujeto a las características de rendimiento del enlace de última milla y por lo tanto es no "externo" en el sentido dado anteriormente. (Estoy seguro de que es posible construir una prueba, pero no tengo tiempo para construir uno ahora).

Answer 2

Puede medir la latencia asimétrica en el enlace enviando paquetes de diferentes tamaños a un puerto que devuelve un tamaño fijo paquete, como enviar algunos paquetes udp a un puerto que responde con un mensaje de error icmp. El mensaje de error icmp siempre tiene el mismo tamaño, pero puede ajustar el tamaño del paquete udp que está enviando.

ver http://www.cs.columbia.edu/techreports/cucs-009-99.pdf

Answer 3

Hay un proyecto llamado ping unidireccional (OWAMP) específicamente para resolver este problema. La actividad se puede ver en el LKML para agregar marcas de tiempo de alta resolución a los paquetes entrantes (SO_TIMESTAMP, SO_TIMESTAMPNS, etc.) para ayudar en el cálculo de esta estadística.

http://www.internet2.edu/performance/owamp/

Incluso hay una versión de Java:

http://www.av.it.pt/jowamp/

Nota ese paquete sellado de tiempo realmente necesita el soporte de hardware y muchos NICs presente generación sólo ofrecen una resolución de milisegundos que puede estar fuera de sincronía con el reloj del anfitrión. Hay artículos de MSDN en el DDK sobre la sincronización de los relojes host NIC & que demuestran problemas potenciales. Las marcas de tiempo en nanosegundos del TSC son problemáticas debido a las diferencias centrales y pueden requerir que la arquitectura de Nehalem funcione adecuadamente a las resoluciones requeridas.

http://msdn.microsoft.com/en-us/library/ff552492(v=VS.85).aspx