Характеристики задержек пакетов

В этом разделе мы более формально рассмотрим характеристики производительности сети, относящиеся к задержкам и потерям пакетов.

Односторонняя задержка пакетов (One-Way Delay Metric, OWD) входит в число стандартов IPPM и описана в RFC 2679 (http://www.ietf.org/rfc/rfc2679.txt).

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

Так как в этом определении учитывается время буферизации пакета узлом-получателем, то задержка зависит от размера пакета, и для получения сопоставимых результатов желательно в определении типа пакетов задавать определенный размер пакета. RFC 2679 не поясняет, почему было выбрано определение задержки, зависящее от размера пакета, но можно предполагать, что это связано с удобством измерения времени прихода пакета, так как программно его можно измерить только после завершения записи всего пакета в буфер операционной системы. Да и понять, относится ли пакет к нужному типу, при получении только его первого бита также невозможно.

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

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

И, наконец, RFC 2679 рекомендует использовать следующие статистические оценки для одностороннего времени задержки:

  • квантиль для некоторого процента, при этом само значение процента не оговаривается;
  • среднее значение задержки;
  • минимальное значение задержки (в выборке).

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

Время реакции сети представляет собой интегральную характеристику производительности сети с точки зрения пользователя. Именно эту характеристику имеет в виду пользователь, когда говорит: «Сегодня сеть работает медленно».

Время реакции сети можно представить в виде нескольких слагаемых, например (рис. 1): времени подготовки запросов на клиентском компьютере (tклиент1), времени передачи запросов между клиентом и сервером через сеть (tсеть), времени обработки запросов на сервере (tсервер) времени передачи ответов от сервера клиенту через сеть (снова tсеть) и времени обработки получаемых от сервера ответов на клиентском компьютере (tклиент2).

Время реакции сети характеризует сеть в целом, в том числе качество работы аппаратного и программного обеспечения серверов. Для того чтобы отдельно оценить транспортные возможности сети, используется другая характеристика — время оборота данных по сети.

Время оборота пакета (Round Trip Time, RTT) входит в число стандартов IPPM, описано в RFC 2681 (http://www.ietf.org/rfc/rfc2681.txt). Время оборота является составляющей времени реакции сети — это «чистое» время транспортировки данных от узла отправителя до узла назначения и обратно без учета времени, затраченного узлом назначения на подготовку ответа:

RTT = 2 х tсеть

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

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

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

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

Вариация задержки пакета (IP Packet Delay Variation, IPDV), которая входит в число стандартов IPPM, описана в RFC 3393 (http://www.ietf.org/rfc/rfc3393.txt).

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

Единичное значение оценки вариации задержки определяется в RFC 3393 как разность односторонних задержек для пары пакетов заданного типа, полученных на интервале измерений Т.

Как и для односторонней задержки, тип пакета может задаваться любыми признаками, однако для определенности измерений вариации задержки размеры обоих пакетов пары должны быть одинаковыми. Основной вопрос в этом определении — каким образом выбрать пару пакетов на интервале измерения Г? Для ответа на этот вопрос в RFC 3393 вводится дополнительная функция — так называемая избирательная функция, которая и определяет правила выбора пары пакетов. Стандарт не определяет точное значение этой функции, он только говорит, что она должна существовать, и дает примеры возможных функций. Например, пары могут образовываться из всех последовательных пакетов, полученных на интервале; другим примером является выбор пакетов с определенными номерами в последовательности полученных пакетов, например пакетов с номерами 1, 5, 10,15 и т. д. с интервалом 5.

Для оценки вариации задержки в соответствии с рекомендациями RFC 3393 требуется измерение задержек определенных пар пакетов. В то же время часто используется другой подход к определению вариации задержки, требующий только знания выборки односторонних задержек без их группировки в пары, отвечающие определенным условиям. Например, в уже упоминавшемся документе «Метрики IP-производительности для пользователей» в качестве оценки вариации задержки предлагается так называемый разброс задержки (delay spread). Разброс задержки определяется как разность между 75- и 25-процентными квантилями односторонней задержки. Таким образом, для того чтобы оценить вариацию задержки по этому определению, достаточно получить выборку значений односторонней задержки, а затем найти соответствующие квантили.