Medición de latencia de red unidireccional

20

Este es un rompecabezas sobre la medición de la latencia de red que creé. Creo que la solución es que es imposible, pero los amigos no están de acuerdo. Estoy buscando explicaciones convincentes de cualquier manera. (Aunque se plantea como un rompecabezas, creo que encaja en este sitio web debido a su aplicabilidad al diseño y la experiencia de los protocolos de comunicación, como en los juegos en línea, sin mencionar NTP).

Suponga que dos robots están en dos habitaciones, conectados por una red con latencias unidireccionales diferentes, como se muestra en el siguiente gráfico. Cuando el robot A envía un mensaje al robot B, tarda 3 segundos en llegar, pero cuando el robot B envía un mensaje al robot A, tarda 1 segundo en llegar. Las latencias nunca varían.

Los robots son idénticos y no tienen un reloj compartido, aunque pueden medir el paso del tiempo (por ejemplo, tienen cronómetros). No saben cuál de ellos es el robot A (cuyos mensajes se retrasan 3s) y cuál es el robot B (cuyos mensajes se retrasan 1s).

Un protocolo para descubrir el tiempo de ida y vuelta es:

whenReceive(TICK).then(send TOCK)

// Wait for other other robot to wake up
send READY
await READY
send READY

// Measure RTT
t0 = startStopWatch()
send TICK
await TOCK
t1 = stopStopWatch()
rtt = t1 - t0  //ends up equalling 4 seconds

¿Existe un protocolo para determinar los retrasos en el viaje de ida? ¿Pueden los robots descubrir cuál de ellos tiene el retraso de envío de mensajes más largo?

Dos robots una red asimétrica

computer-networks protocols distributed-systems

— Craig Gidney
fuente

55

Consulte Sincronización de reloj en una red con retrasos asimétricos (que pide algo factible con la infraestructura típica de Internet). Creo que por lo que vimos cuando discutimos las respuestas incorrectas a esa pregunta, la respuesta a su pregunta es que es imposible.

— Gilles 'SO- deja de ser malvado'

¿Deberíamos fusionar las preguntas, o son lo suficientemente diferentes en el objetivo para mantenerse separadas?

— Craig Gidney

No, son preguntas diferentes. Su pregunta establece que es imposible en una configuración de dos máquinas con solo pasar un mensaje. Espero soluciones basadas en, digamos, que la información de latencia esté disponible para algunos enlaces intermedios en la ruta entre el cliente y el servidor y que tenga alguna forma de propagar esta información al cliente.

— Gilles 'SO- deja de ser malvado'

3

Si hubiera una manera de hacer esto, la teoría de la relatividad de Einstein no funcionaría, ya que depende del hecho de que dos observadores que están separados por el espacio y tienen latencias unidireccionales desconocidas no pueden ponerse de acuerdo en un momento adecuado.

— Peter Shor

De hecho, NTP permite / implementa la medición de este retraso diferencial basado en máquinas que se envían entre sí su tiempo y no solo rastrean el tiempo de envío / recepción de sus propios mensajes, sino también los otros servidores a través del contenido de mensajes, vea la respuesta en la pregunta de

— Gilles

14

El siguiente diagrama, de una publicación de blog que escribí , es una prueba visual de que es imposible:

Deslizando la inclinación del reloj exactamente compensada por la asimetría de latencia

Observe cómo los tiempos de llegada de paquetes en cada lado permanecen iguales, incluso cuando las latencias unidireccionales cambian (¡e incluso se vuelven negativas!). El primer paquete siempre llega al servidor a las 1.5 s en el reloj del servidor, el segundo siempre llega al cliente a las 2 s en el reloj del cliente, etc. El contenido del paquete y las horas de llegada locales son las únicas cosas en las que se puede basar un protocolo, pero el los contenidos y los tiempos de llegada pueden mantenerse constantes ya que la asimetría varía al variar también la inclinación inicial del reloj.

Básicamente, la asimetría en las latencias unidireccionales se ve exactamente como la inclinación del reloj. Dado que el problema indica que no comenzamos conociendo el sesgo inicial del reloj o la asimetría de latencia unidireccional, y variar uno parece variar el otro para que sus efectos sean indistinguibles, no podemos separar sus contribuciones para resolver el problema. asimetría de latencia unidireccional. Es imposible.

$n-1$ $n-1$

Enfermedad del mar

Si no eres tan visualmente inclinado, tengo otro argumento intuitivo. Imagine un portal de tiempo para cien años en el futuro. Cuando conversas con alguien del otro lado, te das cuenta de que la conversación es totalmente normal a pesar de la asimetría de cien años en retrasos unidireccionales. ¡Cualquier efecto observable habría sido obvio en esa escala!

— Craig Gidney
fuente

¿Cuál es tu opinión sobre esto? software.internet2.edu/owamp

— CMCDragonkai

@CMCDragonkai Tenga en cuenta que la declaración del rompecabezas es más restrictiva que la realidad. En la práctica, tiene opciones como medir la longitud de las líneas de fibra óptica, iniciar sesión en puntos intermedios, usar el conocimiento de la topología de la red, transportar lentamente un reloj de un lugar a otro, etc. Por ejemplo, los satélites GPS se mueven en órbitas conocidas y usted puede usar eso para eliminar grados de libertad al resolver. Así que en la superficie no veo ningún problema con una herramienta de ping unidireccional, siempre y cuando los relojes en los que se basa estén explotando parte de esa dulce información terciaria dulce.

— Craig Gidney

Ah, en ese caso, ¿podrías actualizar tu respuesta con posibles soluciones?

— CMCDragonkai

@CMCDragonkai Tenerlos en los comentarios es suficiente. Están más allá del alcance del rompecabezas.

— Craig Gidney

La latencia unidireccional sí importa, por ejemplo, para las redes de juegos. Además, todo el mundo dice que es imposible, pero puedo resolver fácilmente el rompecabezas en papel: una vez que sincroniza los relojes, todo lo que hace es medir el retraso de A a B enviando el tiempo de A a B, con A-> B de retraso igual a B's time - A's sent time, y B-> A siendo igual alatency - A->B delay

— Llamageddon el

1

Creo que es imposible determinar la latencia unidireccional simplemente comparando cronómetros.

$A$ $B$ $C_{A1}$
$B$ $C_{B1}=1$
$A$ $C_{A2}=9$
$B$ $C_{B2}=5$
$A$ $B$

Tal vez si lo conviertes en una pregunta de recompensa, alguien lo resolverá. Hasta entonces, felicitaciones.

— rath
fuente

0

He encontrado una manera de AMBOS descubrir qué nodo es quién (es decir, quién tiene el retraso de mensaje más largo) Y estimar el retraso de viaje de ida. Si bien las otras respuestas son correctas, SOLO están considerando la medición directa del reloj que, por supuesto, no puede funcionar. Sin embargo, como estoy demostrando aquí, esto es solo una parte de la historia, ya que aquí está mi algoritmo de trabajo para lo anterior:

Asumir como en la vida real:

Enlaces de ancho de banda finito b
Cada nodo tiene una dirección única (por ejemplo, A y B)
Tamaño de paquete p mucho más pequeño que el ancho de banda * producto de latencia
Los nodos A y B pueden llenar el canal
Los nodos tienen una función aleatoria ()

Cada nodo llena el canal con sus propios paquetes (marcados con A o B respectivamente) O reenvía los paquetes que recibió de otros nodos de la siguiente manera:

Always fill the channel with my own packets except:
if I receive a packet from another node then
   Randomly choose to 
          either forward that packet from the other node
          or discard that packet and forward my own packet

Explicación intuitiva Dado que el producto de latencia de ancho de banda * de A es mayor (porque la latencia es mayor) A logrará recibir más paquetes que B, por lo tanto, cada nodo puede saber quiénes son en el diagrama .

Además, con suficiente tiempo de convergencia de ejecución por encima del algoritmo, la proporción de paquetes de A a B denotará la proporción real de retraso RTT de A a B y, por lo tanto, la OTT deseada .

RASTREO DE RESULTADOS DE SIMULACIÓN Aquí hay una simulación que demuestra lo anterior y muestra cómo A converge exitosamente hacia un retraso de 3 segundos y B converge alrededor de un retraso de 1 segundo:

Primeros segundos de simulación

Segundos posteriores de simulación

Explicación de las figuras: cada línea representa 1 segundo de tiempo (el tamaño del paquete se elige para tener 1 segundo de tiempo de transmisión para mayor claridad). Tenga en cuenta que cada nodo puede iniciar el algoritmo en cualquier momento, no en una secuencia o tiempo particular. Las columnas son las siguientes:

NODO A recibe: lo que ve el nodo A en su lado receptor (esto también es P4 a continuación)
NODO A inyecta: qué nodo A envía (tenga en cuenta que esto es A, o aleatoriamente A o B)
P1, P2, P3: los tres paquetes que están en tránsito (en orden) entre A y B (1 segundo de transmisión significa que 3 paquetes están en tránsito para una latencia de 3)
NODO B recibe: lo que B ve en su lado receptor (esto es P3)
NODE B inyecta: lo que B envía (tenga en cuenta que esto es B, o aleatoriamente A o B por algo)
P4: El paquete en tránsito de B a A (ver también P1, P2, P3)
A cuenta A: lo que A cuenta para los paquetes A que ha visto
A cuenta B: lo que A cuenta para los paquetes B que ha visto
B cuenta A: lo que B cuenta para los paquetes A que ha visto
B cuenta B: lo que B cuenta para los paquetes B que ha visto
A-> B: La latencia que A estima hacia B (relación de RTT de 4 segundos según los paquetes vistos)
B-> A: La latencia que B estima hacia A (relación de RTT de 4 segundos según los paquetes vistos)

Como podemos ver, ambos nodos convergen y permanecen alrededor de su latencia verdadera (en realidad no vemos eso para A porque se necesitan más segundos para converger pero sí converge el mismo comportamiento que B)

Los mejores filtros podrían converger más rápido, pero podemos ver claramente cómo ambos convergen en torno a los valores correctos para sus retrasos, por lo tanto, pueden saber exactamente cuál es su retraso (aunque estoy mostrando su estimación solo como ilustración).

Además, incluso si los anchos de banda entre los enlaces son diferentes, el método anterior podría mantenerse (aunque uno tendrá que pensarlo más para estar más seguro) al usar pares de paquetes para calcular las estimaciones de ancho de banda y luego simplemente aplicar a la ecuación de proporción anterior.

Conclusión Proporcionamos un algoritmo para que A y B conozcan su posición en la red y conozcan su latencia al otro nodo para el diagrama anterior. Utilizamos un método de estimación de medición de red en lugar de enfoques basados en el reloj que, de hecho, no pueden conducir a una solución debido a un problema de sincronización del reloj recursivo.

Tenga en cuenta que ahora edité esta respuesta proporcionando todas las simulaciones porque nadie me creería. Lo resolví hasta donde puede ver en los primeros comentarios. ¡Esperemos que con estos resultados alguien pueda estar más convencido y aprobar ayudar a todos al menos a encontrar un error o corrección en este rompecabezas de medición de red!

— usuario3134164
fuente

3

No creo que esto funcione. Como el ancho de banda es el mismo, la única diferencia que A y B ven es que, si comenzaran al mismo tiempo, B esperaría 3 segundos antes de recibir cualquier dato y A esperaría 1 segundo. Pero no tienen un reloj compartido, por lo que no saben que comenzaron al mismo tiempo. Tal vez A no escuche nada durante 10 segundos porque primero comenzó a ejecutar el protocolo.

— David Richerby

No hay ningún requisito para comenzar al mismo tiempo que cualquiera puede comenzar en cualquier momento, solo ambos tienen que correr por algún tiempo. Le agradezco que se haya tomado el tiempo de revisar, pero lea nuevamente Este es un método estadístico e implica convergencia. No digo que sea 100%, es absolutamente correcto ya que no he simulado, pero el comentario que hizo no se aplica realmente en mi opinión. Tal vez esto explica la idea de manera más general: si acepta que el ancho de banda * del producto de retardo es diferente para los dos enlaces, un enlace de hecho contendrá más paquetes, y eso puede ser detectado por algo anterior ...

— user3134164

No creo haber entendido mal, pero es posible. ¿Está de acuerdo en que el ancho de banda es el mismo para que tanto A como B reciban datos a la misma velocidad? Si es así, ¿no convergerán ambos exactamente a la misma cosa?

— David Richerby

Sí, por supuesto, reciben a la misma velocidad, eso no significa que converjan en la misma cosa. Hay paquetes A y B en la red, la pregunta es cuál es la proporción de paquetes A vs B vistos. Realicé una simulación simple ahora y obtengo el sesgo todo el tiempo. Para tener una idea, ya que supongo que no puedo publicar todo esto, supongo que b es tal que 1 paquete requiere una transmisión de un segundo. Entonces siempre hay 4 paquetes en tránsito. ¡Aplique el algoritmo y el boom que logramos medir OTT evitando métodos sincronizados de reloj / eventos que no funcionan con métodos de convergencia estadística!

— usuario3134164

¿Cuál es "la proporción de paquetes de A vs B"?

— Gilles 'SO- deja de ser malvado'

0

Esta es una respuesta a @ user3134164 pero es demasiado grande para un comentario.

$P_x$ $x$ $R_x$ $x$

$R_1 = (1 - R_2) \times (1 - P_2)$ $R_2 = (1 - R_1) \times (1 - P_1)$ $1 - R_2$ $1 - P_2$
$R_1$ $R_2$ $\frac{R_1}{1 - R_1}$ $\frac{R_2}{1 - R_2}$

Por eso creo que esto no te llevará a ninguna parte. Señale cualquier error que pueda haber cometido durante este razonamiento.

— Matrefeytontias
fuente

Bienvenido a la informática ! Su respuesta se ve bien pero, como usted dice, en realidad es un comentario en profundidad sobre el comentario de @ user3134164. Creo que puede resolver este problema de las siguientes maneras: 1) Intente expandir su respuesta de modo que también sea una respuesta a la pregunta real. o 2) Cree una nueva pregunta que esencialmente indique la idea errónea clave del comentario del usuario3134164 y responda con una respuesta similar a esta. Cuál es el apropiado depende de usted. Creo que tal vez hacer una nueva pregunta es una buena idea, pero tal vez puedas expandirte más de lo que creo. Pregunte si tiene más preguntas.

— Lagarto discreto

Por supuesto, @ user3134164 también es libre de 'promover' el comentario en una pregunta:

— Lagarto discreto

"Px la probabilidad de que el robot x elija sus propios paquetes cuando recibe uno de los paquetes del otro robot" proviene de una función aleatoria () de la computadora como en el supuesto; por ejemplo, para dos tipos de paquetes siempre será 0.5. Si la función random () es lo suficientemente uniforme, se puede calcular la "relación real de retraso RTT de A a B". Según su definición de R, creo que R1 = (1-R2) * 0.5, por lo que se conoce la relación. Así que todavía creo que mi respuesta funciona bien. Muchas gracias por tomarse el tiempo para investigarlo.

— user3134164