Mesurer la latence du réseau unidirectionnel

Il s'agit d'un puzzle sur la mesure de la latence du réseau que j'ai créé. Je crois que la solution est que c'est impossible, mais les amis ne sont pas d'accord. Je cherche des explications convaincantes de toute façon. (Bien qu'il soit posé comme un puzzle, je pense qu'il convient à ce site Web en raison de son applicabilité à la conception et à l'expérience des protocoles de communication tels que dans les jeux en ligne, sans parler de NTP.)

Supposons que deux robots se trouvent dans deux pièces, connectés par un réseau avec des latences unidirectionnelles différentes, comme indiqué dans le graphique ci-dessous. Lorsque le robot A envoie un message au robot B, cela prend 3 secondes pour qu'il arrive, mais lorsque le robot B envoie un message au robot A, il faut 1 seconde pour arriver. Les latences ne varient jamais.

Les robots sont identiques et n'ont pas d'horloge commune, bien qu'ils puissent mesurer le passage du temps (par exemple, ils ont des chronomètres). Ils ne savent pas lequel est le robot A (dont les messages sont retardés de 3s) et lequel est le robot B (dont les messages sont retardés de 1s).

Un protocole pour découvrir le temps d'aller-retour est:

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-t-il un protocole pour déterminer les retards aller simple? Les robots peuvent-ils découvrir lequel d'entre eux a le délai d'envoi de message le plus long?

Le diagramme suivant, tiré d' un article de blog que j'ai écrit , est une preuve visuelle qu'il est impossible:

Remarquez comment les heures d'arrivée des paquets de chaque côté restent les mêmes, même si les latences unidirectionnelles changent (et deviennent même négatives!). Le premier paquet atteint toujours le serveur à 1,5 s sur l'horloge du serveur, le second atteint toujours le client à 2 s sur l'horloge du client, etc. Le contenu du paquet et les heures d'arrivée locales sont les seules choses sur lesquelles un protocole pourrait être basé, mais le le contenu et les heures d'arrivée peuvent être maintenus constants car l'asymétrie varie en variant également le décalage d'horloge initial.

Fondamentalement, l'asymétrie dans les latences unidirectionnelles ressemble exactement à un décalage d'horloge. Étant donné que le problème indique que nous ne commençons pas par connaître le décalage d'horloge initial ou l'asymétrie de latence unidirectionnelle, et que la variation de l'une ressemble à la variation de l'autre, de sorte que leurs effets sont indiscernables, nous ne pouvons pas séparer leurs contributions afin de résoudre le problème. asymétrie de latence unidirectionnelle. C'est impossible.

Plus formellement, vous ne pouvez pas résoudre les longueurs de bord lorsque seules les longueurs des cycles sont données. La base du cycle a degrés de liberté, correspondant à n - 1 biais d'horloge inconnus par rapport à l'un des participants. Vous pouvez toujours masquer les latences unidirectionnelles, même lorsqu'il y a de nombreux participants:$n-1$$n-1$

Si vous n'êtes pas si incliné visuellement, j'ai un autre argument intuitif. Imaginez un portail temporel vers une centaine d'années dans le futur. En discutant avec quelqu'un de l'autre côté, vous réalisez que la conversation est tout à fait normale malgré l'asymétrie centenaire des retards à sens unique. Tout effet observable aurait été évident à cette échelle!

Je pense qu'il est impossible de comprendre la latence à sens unique simplement en comparant les chronomètres.

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

Peut-être que si vous en faites une question de prime, quelqu'un la fera craquer. Jusque-là, bravo.

J'ai trouvé un moyen de DÉCOUVRIR quel nœud est qui (c'est-à-dire qui a le délai de message le plus long) ET d'estimer le délai de déplacement aller simple. Bien que les autres réponses soient correctes, elles envisagent UNIQUEMENT une mesure d'horloge directe qui, bien sûr, ne peut pas fonctionner. Cependant, comme je le prouve ici, ce n'est qu'une partie de l'histoire, car voici mon algorithme de travail pour ce qui précède:

Supposons que dans la vraie vie:

• Liens de bande passante finie b

• Chaque nœud a une adresse unique (par exemple A et B)

• Taille de paquet p beaucoup plus petite que la latence de la bande passante *

• Les nœuds A et B sont capables de remplir le canal

• Les noeuds ont un aléatoire () fonction

Chaque nœud remplit le canal avec ses propres paquets (marqués respectivement A ou B) OU transfère les paquets qu'il a reçus d'autres nœuds comme suit:

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

Explication intuitive Étant donné que le produit de latence de la bande passante * de A est plus élevé (car la latence est plus élevée), A réussira à recevoir plus de paquets que B, donc chaque nœud peut savoir qui ils sont dans le diagramme .

En outre, avec un temps de convergence suffisant pour exécuter l'algorithme ci-dessus, le rapport des paquets de A à B dénotera le rapport réel du délai RTT de A à B et donc l'OTT souhaité .

TRACE DE RÉSULTAT DE SIMULATION Voici une simulation qui prouve ce qui précède et montre comment A converge avec succès vers un retard de 3 secondes et B converge autour d'un retard de 1 seconde:

Explication des figures: Chaque ligne représente 1 seconde de temps (la taille du paquet est choisie pour avoir 1 seconde de temps de transmission pour plus de clarté). Notez que chaque nœud peut démarrer l'algo à tout moment, pas dans une séquence ou un moment particulier. Les colonnes sont les suivantes:

• NODE A reçoit: ce que le nœud A voit de son côté récepteur (c'est également P4 ci-dessous)

• NODE A injecte: ce que le nœud A envoie (notez que c'est A, ou au hasard A ou B)

• P1, P2, P3: Les trois paquets qui sont en transit (dans l'ordre) entre A et B (1 seconde de transmission signifie que 3 paquets sont en transit pour une latence de 3)

• Le NŒUD B reçoit: ce que B voit de son côté récepteur (c'est P3)

• NODE B injecte: ce que B envoie (notez que c'est B, ou au hasard A ou B par algo)

• P4: le paquet en transit de B vers A (voir aussi P1, P2, P3)

• A compte A: ce que A compte pour les paquets A qu'il a vus

• A compte B: ce que A compte pour les paquets B qu'il a vus

• B compte A: ce que B compte pour les paquets A qu'il a vus

• B compte B: ce que B compte pour les paquets B qu'il a vus

• A-> B: La latence qu'A estime à B (rapport de RTT de 4 secondes basé sur les paquets vus)

• B-> A: La latence que B estime à A (rapport de RTT de 4 secondes basé sur les paquets vus)

Comme nous pouvons voir les deux nœuds converger et rester autour de leur vraie latence (en fait, nous ne voyons pas cela pour A car plus de secondes sont nécessaires pour converger mais il converge le même comportement que B)

De meilleurs filtres pourraient converger plus rapidement, mais nous pouvons clairement voir comment ils convergent tous les deux autour des valeurs correctes pour leurs retards, ils peuvent donc connaître exactement leur retard (même si je ne montre leur estimation qu'à titre d'illustration).

De plus, même si les bandes passantes entre les liens sont différentes, la méthode ci-dessus pourrait toujours tenir (bien qu'il faudra y penser davantage pour être plus certain) en utilisant des paires de paquets pour déterminer les estimations de la bande passante et ensuite simplement appliquer à l'équation de proportion ci-dessus.

Conclusion Nous avons fourni un algorithme pour A et B pour connaître leur position dans le réseau et connaître leur latence à l'autre nœud pour le diagramme ci-dessus. Nous avons utilisé une méthode d'estimation de mesure de réseau plutôt que des approches basées sur l'horloge qui, en effet, ne peuvent pas conduire à une solution en raison d'un problème de synchronisation d'horloge récursive.

Remarque J'ai maintenant édité cette réponse en fournissant toutes les simulations car personne ne me croirait, je l'ai résolu autant que vous pouvez le voir dans les premiers commentaires. Espérons qu'avec ces résultats, quelqu'un pourra être plus convaincu et approuver pour aider tout le monde à trouver au moins une erreur ou une correction dans ce puzzle de mesure de réseau!

Ceci est une réponse à @ user3134164 mais est trop gros pour un commentaire.

$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}$

C'est pourquoi je crois que cela ne vous mènera nulle part. Veuillez signaler toute erreur que j'aurais pu commettre lors de ce raisonnement.