Определить асимметричные задержки в сети

Question

Представьте, что у вас есть много кластерных серверов на разных хостах в гетерогенной сетевой среде, так что соединения между серверами могут иметь сильно различающиеся задержки и пропускную способность. Вы хотите построить карту соединений между серверами, передавая данные между ними.

Конечно, эта карта может со временем устареть по мере изменения топологии сети, но давайте пока проигнорируем эти сложности и предположим, что сеть относительно статична.

Учитывая задержки между узлами в этом графе хоста, вычисление полосы пропускания является относительным простым измерением времени. У меня больше проблем с задержками - однако. Чтобы получить время прохождения сигнала в обоих направлениях, достаточно просто синхронизировать пинг в обратном направлении с локального хоста на удаленный хост - оба события синхронизации (запуск, остановка) происходят на локальном хосте.

Что, если я хочу односторонние разы, предполагая, что задержка не одинакова в обоих направлениях? Предполагая, что часы на разных хостах не синхронизированы точно (по крайней мере, их ошибка имеет ту же величину, что и задержки) - как я могу рассчитать одностороннюю задержку?

В смежном вопросе - является ли эта асимметричная задержка (когда ссылка быстрее в направлении, чем другая) распространенной на практике? По каким причинам / конфигурации оборудования? Конечно, я знаю об асимметричных сценариях пропускной способности, особенно на потребительских каналах последней мили, таких как DSL и Cable, но я не уверен в задержке.

Добавлено: После рассмотрения комментария, приведенного ниже, вторая часть вопроса, вероятно, будет лучше для serverfault .

Answer 1

Насколько мне известно, асимметричные задержки - особенно асимметрии "последней мили" - не могут быть определены автоматически, поскольку любой сетевой протокол синхронизации времени одинаково подвержен той же асимметрии, поэтому у вас нет точки ссылка для оценки асимметрии.

Если бы каждая конечная точка имела, например, свои собственные часы GPS, у вас была бы контрольная точка для работы.

In Быстрое измерение параметров LogP для платформ передачи сообщений авторы отмечают, что измерение задержки требует синхронизации часов, внешней по отношению к измеряемой системе. (Выделение жирным шрифтом, курсив в оригинальном тексте.)

Асимметричная задержка может быть измерена только путем отправки сообщения с отметкой времени t _s , и позволить получателю получить задержку из t _r - t _s , где t _r - время приема. Для этого требуется синхронизация часов между отправителем и получателем. Без внешней синхронизации часов (например, с использованием GPS-приемников или специального программного обеспечения, такого как сетевой протокол времени , NTP), часы могут синхронизироваться только до степени детализации времени возврата туда и обратно между двумя хостами [10], что бесполезно для измерения задержки в сети.

Ни один сетевой алгоритм (такой как NTP) не устранит проблемы с каналом последней мили, хотя, поскольку каждый вход в алгоритм сам будет равномерно зависеть от характеристик производительности канала последней мили и, следовательно, не является "внешним" «в том смысле, как указано выше. (Я уверен, что можно создать доказательство, но у меня нет времени, чтобы создать его прямо сейчас.)

Answer 2

Существует проект под названием One-Way Ping (OWAMP) специально для решения этой проблемы. Активность можно увидеть в LKML для добавления временных меток высокого разрешения к входящим пакетам (SO_TIMESTAMP, SO_TIMESTAMPNS и т. Д.), Чтобы помочь в вычислении этой статистики.

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

Есть даже версия Java:

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

Обратите внимание, что метка времени пакета действительно нуждается в аппаратной поддержке, и многие сетевые адаптеры нынешнего поколения предлагают разрешение только в миллисекундах, которое может быть несинхронизировано с тактовой частотой хоста. В DDK есть статьи MSDN о синхронизации часов хоста и сетевого адаптера, демонстрирующие потенциальные проблемы. Временные метки в наносекундах от TSC проблематичны из-за различий в ядре и могут потребовать, чтобы архитектура Nehalem работала должным образом с требуемым разрешением.

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

Answer 3

В отсутствие синхронизированных часов асимметрия не может быть измерена, как доказано в статье 2011 года "Fundamental limits on synchronizing clocks over networks".

https://www.researchgate.net/publication/224183858_Fundamental_Limits_on_Synchronizing_Clocks_Over_Networks

Answer 4

Вы можете измерить асимметричную задержку на линии, отправив пакеты разного размера в порт, который возвращает пакет фиксированного размера, например, отправив несколько пакетов udp в порт, который отвечает сообщением об ошибке icmp. Сообщение об ошибке icmp всегда имеет одинаковый размер, но вы можете настроить размер отправляемого вами пакета udp.

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