Misurazione della latenza della rete a senso unico

Questo è un enigma sulla misurazione della latenza di rete che ho creato. Credo che la soluzione sia impossibile, ma gli amici non sono d'accordo. Sto cercando spiegazioni convincenti in entrambi i casi. (Anche se si pone come un puzzle, penso che si adatti a questo sito Web a causa della sua applicabilità al design e all'esperienza dei protocolli di comunicazione come nei giochi online, per non parlare dell'NTP.)

Supponiamo che due robot si trovino in due stanze, collegate da una rete con diverse latenze unidirezionali, come mostrato nell'immagine seguente. Quando il robot A invia un messaggio al robot B ci vogliono 3 secondi per arrivare, ma quando il robot B invia un messaggio al robot A ci vogliono 1 secondo per arrivare. Le latenze non variano mai.

I robot sono identici e non hanno un orologio condiviso, sebbene possano misurare il passare del tempo (ad es. Hanno cronometri). Non sanno chi di loro è il robot A (i cui messaggi sono ritardati di 3 secondi) e quale è il robot B (i cui messaggi sono ritardati di 1 secondo).

Un protocollo per scoprire il tempo di andata e ritorno è:

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

Esiste un protocollo per determinare i ritardi del viaggio di sola andata? I robot possono scoprire chi ha il ritardo di invio del messaggio più lungo?

Il seguente diagramma, tratto da un post sul blog che ho scritto , è una prova visiva dell'impossibilità:

Nota come i tempi di arrivo dei pacchetti su ciascun lato rimangono gli stessi, anche se le latenze a senso unico cambiano (e diventano persino negative!). Il primo pacchetto raggiunge sempre il server a 1,5 secondi sull'orologio del server, il secondo raggiunge sempre il client a 2 secondi sull'orologio del client, ecc. Il contenuto del pacchetto e gli orari di arrivo locali sono le uniche cose su cui si potrebbe basare un protocollo, ma il i contenuti e i tempi di arrivo possono essere mantenuti costanti poiché l'asimmetria varia anche variando l'inclinazione dell'orologio iniziale.

Fondamentalmente, l'asimmetria nelle latenze a senso unico assomiglia esattamente all'inclinazione dell'orologio. Poiché il problema afferma che non iniziamo a conoscere l'inclinazione dell'orologio iniziale o l'asimmetria della latenza unidirezionale e la variazione di uno sembra variare l'altro in modo che i loro effetti siano indistinguibili, non possiamo separare i loro contributi al fine di risolvere per il asimmetria a latenza unidirezionale. È impossibile.

Più formalmente, non è possibile risolvere le lunghezze dei bordi quando vengono fornite solo le lunghezze dei cicli. La base del ciclo ha gradi di libertà, corrispondenti a inclinazioni di clock sconosciute rispetto a uno dei partecipanti. Puoi sempre nascondere le latenze unidirezionali, anche quando ci sono molti partecipanti:n - $n-1$$n-1$

Se non sei così incline alla vista, ho un altro argomento intuitivo. Immagina un portale temporale per cento anni nel futuro. Mentre chiacchieri con qualcuno dall'altra parte, ti rendi conto che la conversazione è del tutto normale nonostante l'asimmetria centenaria nei ritardi a senso unico. Qualsiasi effetto osservabile sarebbe stato evidente su quella scala!

Penso che sia impossibile capire la latenza unidirezionale solo confrontando i cronometri.

B C A 1 B C B 1 = 1 A C A 2 = 9 B C B 2 = 5 A $A$ invia a suo orologio , diciamo che il suo valore è 5. riconosce il messaggio al momento invia nuovamente il suo orologio, (latenza iniziale + andata e ritorno). riceve al momento . E così via. Né né possono capire quando l'altro robot ha ricevuto un messaggio rispetto ai loro orologi.$B$$C_{A1}$
$B$$C_{B1}=1$
$A$$C_{A2}=9$
$B$$C_{B2}=5$
$A$$B$

Forse se lo fai una domanda generosa qualcuno lo spezzerà. Fino ad allora, complimenti.

Ho trovato un modo per ENTRAMBI scoprire quale nodo è chi (ovvero chi ha il ritardo del messaggio più lungo) E stimare il ritardo del viaggio di sola andata. Mentre le altre risposte sono corrette, stanno SOLO prendendo in considerazione la misurazione dell'orologio diretto che ovviamente non può funzionare. Tuttavia, come sto dimostrando qui, questa è solo una parte della storia in quanto qui è il mio algoritmo di lavoro per quanto sopra:

Assumi come nella vita reale:

• Collegamenti di larghezza di banda finita b

• Ogni nodo ha un indirizzo univoco (ad es. A e B)

• La dimensione del pacchetto p è molto più piccola del prodotto di latenza della larghezza di banda *

• I nodi A e B sono in grado di riempire il canale

• I nodi hanno una funzione random ()

Ogni nodo riempie il canale con i propri pacchetti (contrassegnati rispettivamente con A o B) OPPURE inoltra i pacchetti ricevuti da altri nodi come segue:

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

Spiegazione intuitiva Poiché il prodotto di latenza della larghezza di banda * di A è maggiore (poiché la latenza è maggiore) A riuscirà a ricevere più pacchetti di B, quindi ogni nodo può sapere chi sono nel diagramma .

Inoltre, con un tempo di convergenza sufficiente per l'esecuzione sopra l'algoritmo, il rapporto tra i pacchetti da A a B indicherà il rapporto effettivo del ritardo RTT da A a B e quindi l'OTT desiderato .

TRACCIA DEL RISULTATO DELLA SIMULAZIONE Ecco una simulazione che dimostra quanto sopra e mostra come A convergere con successo verso un ritardo di 3 secondi e B convergere attorno a un ritardo di 1 secondo:

Spiegazione delle figure: ogni riga rappresenta 1 secondo di tempo (la dimensione del pacchetto viene scelta per avere un tempo di trasmissione di 1 secondo per chiarezza). Si noti che ciascun nodo può avviare l'algo in qualsiasi momento, non in una sequenza o momento particolare. Le colonne sono le seguenti:

• NODO A riceve: ciò che il nodo A vede nel suo lato ricevente (questo è anche P4 sotto)

• NODE A inietta: quale nodo A invia (nota che è A, o casualmente A o B)

• P1, P2, P3: I tre pacchetti in transito (in ordine) tra A e B (1 secondo di trasmissione significa che 3 pacchetti sono in transito per una latenza di 3)

• NODE B riceve: ciò che B vede nel suo lato ricevente (questo è P3)

• NODE B inietta: ciò che B invia (nota che è B, o casualmente A o B per algo)

• P4: pacchetto in transito da B ad A (vedi anche P1, P2, P3)

• A conta A: ciò che A conta per i pacchetti A che ha visto

• A conta B: ciò che A conta per i pacchetti B che ha visto

• B conta A: ciò che B conta per i pacchetti A che ha visto

• B conta B: ciò che B conta per i pacchetti B che ha visto

• A-> B: la latenza stimata da A verso B (rapporto di RTT di 4 secondi basato sui pacchetti visti)

• B-> A: la latenza stimata da B verso A (rapporto di RTT di 4 secondi basato sui pacchetti visti)

Come possiamo vedere entrambi i nodi convergere e rimanere attorno alla loro vera latenza (in realtà non lo vediamo per A perché per convergere sono necessari più secondi ma converge lo stesso comportamento di B)

Filtri migliori potrebbero convergere più velocemente, ma possiamo vedere chiaramente come entrambi convergono attorno ai valori corretti per i loro ritardi, quindi possono esattamente conoscere il loro ritardo (anche se sto mostrando la loro stima solo a scopo illustrativo).

Inoltre, anche se le larghezze di banda tra i collegamenti sono diverse, il metodo di cui sopra potrebbe ancora essere valido (anche se si dovrà pensarci più per essere più certi) utilizzando coppie di pacchetti per capire le stime della larghezza di banda e quindi applicare all'equazione delle proporzioni sopra.

Conclusione Abbiamo fornito un algoritmo per A e B per conoscere la loro posizione nella rete e conoscere la loro latenza sull'altro nodo per il diagramma sopra. Abbiamo usato un metodo di stima delle misure di rete piuttosto che approcci basati sull'orologio che in effetti non possono portare a una soluzione a causa di un problema di sincronizzazione dell'orologio ricorsivo.

Nota ora ho modificato questa risposta fornendo tutte le simulazioni perché nessuno mi crederebbe di averlo risolto per quanto si può vedere nei primi commenti. Spero che con questi risultati qualcuno possa essere più convinto e approvare per aiutare tutti almeno a trovare un errore o la correttezza in questo puzzle di misurazione della rete!

Questa è una risposta a @ user3134164 ma è troppo grande per un commento.

Ecco il mio tentativo di mostrare perché questo non può funzionare (approccio matematico). Chiamiamo la probabilità che il robot scelga i suoi pacchetti quando riceve uno dei pacchetti dell'altro robot, e la probabilità che un robot pacchetto sia suo. Dopo che il regime stazionario è stato raggiunto (cioè dopo un "infinito" periodo di tempo, cioè tutta la convergenza è stata fatta), abbiamo quanto segue:$P_x$$x$$R_x$$x$

• R 2 = ( 1 - R 1 ) × ( 1 - P 1 ) 1 - R 2 1 - P $R_1 = (1 - R_2) \times (1 - P_2)$ e similmente . L'idea è che se un robot riceve uno dei suoi pacchetti, significa che l'altro robot l'ha ricevuto invece di uno dei suoi (da qui l' ) e che ha ancora scelto di inviarlo invece di uno dei suoi (quindi il prodotto da ).$R_2 = (1 - R_1) \times (1 - P_1)$$1 - R_2$$1 - P_2$
• Questo dà un sistema di due equazioni con due incognite, e . Potresti volerlo risolvere, ma non importa davvero. In effetti, i rapporti che stai cercando sono rispettivamente e . Come puoi notare, gli unici termini che compaiono in quelle espressioni sono le probabilità in cui ciascun robot sceglie il proprio pacchetto rispetto all'altro. Le latenze non compaiono nemmeno nella formula semplicemente perché entrambi i robot pompano costantemente i pacchetti, quindi entrambi ricevono costantemente pacchetti. Riceveranno effettivamente rapporti di pacchetti diversi, ma dipenderà solo dalle suddette probabilità.R 2 R $R_1$$R_2$ R$\frac{R_1}{1 - R_1}$$\frac{R_2}{1 - R_2}$

Questo è il motivo per cui credo che questo non ti porterà da nessuna parte. Per favore, sottolinea qualsiasi errore che avrei potuto fare durante questo ragionamento.