RFC6349: какие параметры необходимо учитывать при измерении пропускной способности сети?

Каждый из нас задавался вопросом, почему фильм или файл качается со скоростью ниже, чем скорость, заявленная провайдером. Например, скорость 50 Мбит/сек, а скорость в программе для скачивания не более 5-6 Мбит/сек.

Многие приложения работают на основе транспортного протокола TCP, например, HTTP, HTTPS, FTP и т. д. И не многие знают, что на производительность приложения в целом влияет не только канальный (MAC) или сетевой уровень (IP), но и транспортный (TCP или UDP), да и все другие. Так как пользовательский компьютер или сервер могут и умеют тормозить. Для решения этой проблемы и принимая во внимание, что корпоративные приложений практически все работают на основе TCP, в 2010 году собрались представители VIAVI Solutions, Bell Canada и Deutsche Telecom и создали рекомендацию RFC 6349.

RFC6349 - это новая методология тестирования пропускной способности каналов связи на транспортном уровне, которая опубликована Internet Engineering Task Force (IETF) и рекомендуется к использованию в дополнение к тестам на MAC и IP уровне (стандарт ITU-T Y.1564), что позволит повысить производительность корпоративных приложений и арендуемых каналов связи.

В рекомендации RFC6349 описаны параметры, которые влияют на пропускную способность канала связи, как провести необходимые измерения в полевых условиях и интерпретировать результаты:

• определение максимального размера полезного блока данных одного пакета (MTU) в соответствии с RFC 4821 на всем пути следования, что позволит определить максимальный размер пакета без фрагментации полезной нагрузки;
• измерение базовой круговой задержки и минимальной пропускной способности для определения оптимального размера окна (TCP window size) и расчета TCP Bandwidth-Delay Product (BDP);
• выполнение нескольких измерений пропускной способности сети на транспортном уровне, чтобы максимально заполнить трубу с выявленными параметрами на предыдущих этапах.

Опишем каждый из этих этапов более подробно.

Определение MTU по RFC 4821

Протокол TCP использует технологию определения максимального размера полезного блока данных одного пакета (PMTUD) на основе протокола Internet Control Message Protocol (ICMP). Каждый из нас может проверить MTU на пути следования к какому либо ресурсу. Для этого достаточно выполнить Ping с дополнительными параметрами:

Если сетевому устройству необходимо передать пакет без его фрагментации, то в IP заголовке есть специальное поле, которое разрешает или запрещает использовать фрагментацию (DF).

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

Но в реальных сетях сетевые специалисты блокируют передачу ICMP, что делает механизм подстройки MTU невозможным. Поэтому RFC6349 рекомендует протестировать каналы связи и определить MTU для всего пути следования пакетов в соответствии с RFC 4821, который может работать с или без поддержки протокола ICMP - Packetization Layer Path MTU Discovery (PLPMTUD).

Базовая круговая задержка и минимальная пропускная способность

Базовая круговая задержка (baseline round-trip time, RTT) — это время, необходимое для передачи полного TCP сегмента: от первого бита до последнего. Данный параметр измеряется в момент минимальной нагрузки на каналы связи. Если тестирование выполняется в период активной нагрузки, то измерения надо сделать несколько раз и выбрать минимальное время для того чтобы принять его как базовое. Как можно измерить базовую круговую задержку:

• подключить два измерительных прибора по обе стороны канала связи и выполнить измерения в соответствии с RFC5357;
• выполнить захват трафика с помощью анализатора протоколов и вычислить время на этапе установления TCP соединения — тройное рукопожатие между пакетами SYN и SYN-ACK;
• выполнить PING, но следует понимать, что ICMP имеет самый низкий приоритет с точки зрения TOS, DSCP.

Минимальная пропускная способность (bottleneck bandwidth, BB) измеряется в обоих направлениях, особенно если каналы асимметричны и в разные периоды дня, чтобы взять именно минимальное значение. Для этого можно выполнить классический тест в соответствии с RFC2544 или Y.1564.

Далее эти два параметра используются для расчета минимально требуемого размера окна TCP (TCP receive window, RWND) и размера буфера для оптимальной производительности на TCP уровне:

BDP (bits) = RTT (sec) * BB (bps)

Min TCP RWND = BDP(bits) / 8

После определения минимального размера TCP окна мы можем рассчитать пропускную способность на TCP уровне:

TCP Throughput = TCP RWND * 8 / RTT

Например, мы арендуем канал 100 Мбит/сек и круговая задержка составляет 10 мсек, а размер окна настроен на 64 Кбайт, тогда пропускная способность составит:

TCP Throughput = 64000*8/0,01 = 51,2 Мбит/сек

Для того чтобы рассчитать максимально возможную пропускную способность необходимо воспользоваться формулой:

Maximum TCP Throughput = (MTU - 40) in Bytes * 8 bits * max FPS

FPS – Frame per second на физическом уровне. Для Ethernet рассчитывается следующим образом:

FPS = (Speed (Mbps) / (1538 Bytes * 8 bits))

Как получается 1538 байта = 1500 (MTU) + 14 (заголовок Ethernet) + 4 (CRC32) + 12 (Inter-Frame Gap) + 7 (преамбула) + 1 ( Start of Frame Delimiter).

Таким образом, для канала 100 Мбит/сек максимальное значение составит:

FPS = (100/ (1538*8)) = 8127 бит/сек

Maximum TCP Throughput = (1500 - 40) * 8* 8127 = 94,9 Мбит/сек

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

Всегда на связи, Игорь Панов.

Делитесь нашими статьями в соцсетях и задавайте вопросы в комментариях!

Обзор решений Viavi Solutions: Observer Matrix и Observer TAPs

Методология DevOps и её влияние на облачные системы мониторинга

Скрытые расходы, о которых любят молчать поставщики решений NPMD и APM