Вимірювання одного способу затримки в мережі

Це загадка про вимірювання мережевої затримки, яку я створив. Я вважаю, що рішення полягає в тому, що це неможливо, але друзі не згодні. Я так чи інакше шукаю переконливих пояснень. (Хоча вона і поставлена ​​як головоломка, я думаю, що вона підходить для цього веб-сайту через його застосовність до дизайну та досвіду комунікаційних протоколів, таких як в онлайн-іграх, не кажучи вже про NTP.)

Припустимо, два роботи знаходяться у двох приміщеннях, з'єднаних мережею з різними односторонніми затримками, як показано на малюнку нижче. Коли робот A надсилає повідомлення роботові B, йому потрібно 3 секунди, а коли робот B надсилає повідомлення роботові A, на його приїзд потрібна 1 секунда. Затримки ніколи не змінюються.

Роботи однакові і не мають спільного годинника, хоча вони можуть вимірювати час (наприклад, вони мають годинник). Вони не знають, хто з них - робот A (повідомлення якого затримані 3 секунди), а який - робот B (повідомлення якого затримуються на 1 секунду).

Протокол для виявлення часу туди і назад:

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

Чи є протокол, який визначає затримку подорожі в одну сторону? Чи можуть роботи виявити, хто з них має більш тривалу затримку відправки повідомлень?

Наступна діаграма із написаного мною блогу є наочним доказом того, що це неможливо:

Зауважте, як час прийому пакетів з кожної сторони залишається однаковим, навіть коли однобічні затримки змінюються (і навіть стають негативними!). Перший пакет завжди доходить до сервера за 1,5 секунди на годиннику сервера, другий завжди досягає клієнта за 2 секунди на годиннику клієнта і т. Д. Зміст пакету та локальний час приходу - це єдине, на чому може базуватися протокол, вміст та час прибуття можуть бути постійними, оскільки асиметрія змінюється, змінюючи також початковий перекіс годинника.

В основному, асиметрія в односторонніх затримках виглядає точно як перекос годинника. Оскільки проблема говорить про те, що ми не починаємо знати початковий перекіс годинника або односильну асиметрію затримки, і коли одна зміна виглядає як інша, так що їх ефекти не відрізняються, ми не можемо відокремити їх внесок для вирішення проблеми одностороння асиметрія затримки. Це неможливо.

Більш формально, ви не можете вирішити довжину ребер, якщо задати лише довжини циклів. Основа циклу має ступінь свободи, що відповідає n $n-1$ невідомим перекосам годинника відносно одного з учасників. Ви завжди можете приховати затримки в одну сторону, навіть якщо учасників багато:$n-1$

Якщо ти не такий візуально схильний, у мене є інший інтуїтивний аргумент. Уявіть собі портал часу на сто років у майбутньому. Під час спілкування з кимось з іншого боку ви розумієте, що розмова цілком нормальна, незважаючи на сторічну асиметрію в односторонніх затримках. Будь-який помітний ефект був би очевидним у такому масштабі!

Я думаю, що неможливо визначити однобічну затримку, лише порівнявши секундоміри.

$A$$B$$C_{A1}$
$B$$C_{B1}=1$
$A$$C_{A2}=9$
$B$$C_{B2}=5$
$A$$B$ можуть зрозуміти, коли інший робот отримав повідомлення щодо годинника.

Можливо, якщо ви зробите це щедрим питанням, хтось його зламає. До цього часу, кудо.

Я знайшов спосіб дізнатися, який вузол є хто (тобто у кого більша затримка повідомлень) та оцінити однобічну затримку подорожі. Хоча інші відповіді правильні, вони ТІЛЬКИ враховують пряме вимірювання годин, що, звичайно, не може працювати. Однак, як я доказую тут, це лише частина історії, оскільки тут працює мій алгоритм для вищезазначеного:

Припустимо, як у реальному житті:

• Посилання кінцевої пропускної здатності b

• Кожен вузол має унікальну адресу (наприклад, A і B)

• Розмір пакету p набагато менший, ніж продукт із затримкою пропускної здатності *

• Вузли А і В здатні заповнити канал

• Вузли мають випадкову () функцію

Кожен вузол заповнює канал власними пакетами (позначеними відповідно А або В) АБО пересилає отримані пакети від інших вузлів наступним чином:

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

Інтуїтивне пояснення Оскільки продукт затримки * пропускної здатності * більший (оскільки затримка вище), A вдасться отримати більше пакетів, ніж B, тому кожен Вузол може знати, хто вони на діаграмі .

Крім того, при достатньому часі конвергенції, що працює вище алгоритму, відношення пакетів від A до B буде позначати фактичне відношення RTT затримки від A до B і, отже, бажане OTT .

РЕЗУЛЬТАТ МІЖУВАННЯ РЕЗУЛЬТАТИ Ось моделювання, яке доводить вищесказане і показує, як успішно конвергується до затримки на 3 секунди і B конвергується близько 1 секунди затримки:

Пояснення фігур: Кожен рядок представляє 1 секунду часу (розмір пакета вибирається таким, щоб мати зрозумілість 1 секунди для передачі). Зауважте, що кожен вузол може запустити algo в будь-який час, не в певній послідовності чи часі. Стовпці такі:

• NODE A отримує: те, що вузол A бачить у своїй приймальній стороні (це також P4 нижче)

• NODE A вводить: який вузол A надсилає (зверніть увагу, що це A, або випадково A або B)

• P1, P2, P3: Три пакети, які перебувають у транзиті (в порядку) між A і B (1 секунда передачі означає, що 3 пакети перебувають у транзиті з затримкою 3)

• NODE B отримує: що B бачить у своїй приймальній стороні (це P3)

• NODE B вводить: те, що B надсилає (зверніть увагу, що це B, або випадково A або B на альго)

• P4: Пакет, який проходить транзитом від B до A (див. Також P1, P2, P3)

• Лічильник A: Що A вважає для пакетів A, які він бачив

• A рахує B: Що A вважається для B пакетів, які він бачив

• B рахує A: Що B вважає для пакетів A, які він бачив

• B рахує B: Що вважає B для B-пакетів, які він бачив

• A-> B: затримка, яку A оцінює до B (відношення RTT 4 секунди на основі бачених пакетів)

• B-> A: затримка, яку B оцінює до A (відношення RTT 4 секунди на основі бачених пакетів)

Як ми можемо бачити, як обидва вузли сходяться і залишаються навколо їхньої справжньої затримки (насправді ми не бачимо, що для A потрібно більше секунд, щоб сходитись, але це конвергує таку ж поведінку, що і B)

Кращі фільтри можуть конвергуватися швидше, але ми можемо чітко бачити, як вони обидві конвергуються навколо правильних значень для їх затримок, тому вони можуть точно знати їх затримку (хоча я показую їх оцінку лише для ілюстрації).

Крім того, навіть якщо пропускна здатність між посиланнями відрізняється, вищезазначений метод все-таки може дотримуватися (хоча доведеться думати про це більше, щоб бути більш впевненим), використовуючи пари пакетів, щоб визначити оцінки пропускної здатності, а потім просто застосувати до рівняння пропорції вище.

Висновок Ми запропонували алгоритм для A і B, щоб знати їх положення в мережі та знати їх затримку до іншого вузла для наведеної вище діаграми. Ми використовували метод оцінки мережевих вимірювань, а не підходи, засновані на тактовій частоті, які насправді не можуть призвести до рішення через проблему рекурсивної синхронізації годин.

Примітка. Зараз я відредагував цю відповідь, надаючи всі симуляції, тому що ніхто не повірив мені, що я вирішив її так далеко, як ви можете бачити в перших коментарях. Сподіваємось, у цих результатах хтось може бути більш переконаний і схвалити допомогти кожному хоча б знайти одну помилку чи правильність у цій мережевій головоломці!

Це відповідь на @ user3134164, але занадто великий для коментаря.

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

Ось чому я вважаю, що це вас нікуди не приведе. Будь ласка, вкажіть будь-яку помилку, яку я могла допустити під час цих міркувань.