Tcp pacing что это

ИТ База знаний

Полезно

— Онлайн генератор устойчивых паролей

— Онлайн калькулятор подсетей

— Руководство администратора FreePBX на русском языке

— Руководство администратора Cisco UCM/CME на русском языке

— Руководство администратора по Linux/Unix

Навигация

Серверные решения

Телефония

FreePBX и Asterisk

Настройка программных телефонов

Корпоративные сети

Протоколы и стандарты

Установление и прекращение TCP соединения

3 часть. СИН-АК-СИНАК

Полный курс по Сетевым Технологиям

В курсе тебя ждет концентрат ТОП 15 навыков, которые обязан знать ведущий инженер или senior Network Operation Engineer

Установление TCP-соединения происходит до того, как любая из других функций TCP сможет начать свою работу. Установление соединения относится к процессу инициализации полей «Sequence» и «Acknowledgment» и согласования используемых номеров портов. На рисунке 5 показан пример процесса установления соединения.

TCP сообщает об установлении соединения, используя 2 бита в полях флагов заголовка TCP. Эти биты, называемые флагами SYN и ACK, имеют особенно интересное значение. SYN означает «синхронизировать порядковые номера», что является одним из необходимых компонентов при инициализации TCP.

Восстановление после ошибок и надежность

TCP обеспечивает надежную передачу данных, что также называется reliability or error recovery. Для обеспечения надежности TCP нумерует байты данных, используя поля «Sequence» и «Acknowledgment» в заголовке TCP. TCP обеспечивает надежность в обоих направлениях, используя поле Sequence Number одного направления в сочетании с полем Acknowledgment в противоположном направлении.

Однако этот пример не исправляет никаких ошибок; он просто показывает основы того, как хост-отправитель использует поле порядкового номера для идентификации данных, а хост-получатель использует прямые подтверждения для подтверждения данных. Более интересное обсуждение вращается вокруг того, как использовать эти же инструменты для восстановления ошибок. TCP использует поля «Sequence» и «Acknowledgment«, чтобы принимающий хост мог заметить потерю данных, попросить отправляющий хост повторно отправить, а затем подтвердить, что повторно отправленные данные прибыли.

Существует множество вариантов того, как TCP выполняет исправление ошибок. На рисунке 8 показан только один такой пример, детализация которого аналогична предыдущему. Веб-браузер снова отправляет три сегмента TCP, снова по 1000 байт каждый, снова с легко запоминающимися порядковыми номерами. Однако в этом примере второй сегмент TCP не может пройти через сеть.

Рисунок указывает на три набора идей, лежащих в основе того, как думают два хозяина. Во-первых, справа сервер понимает, что он не получил все данные. Два полученных сегмента TCP содержат байты с номерами 10001999 и 30003999. Очевидно, сервер не получил байты, пронумерованные между ними. Затем сервер решает подтвердить все данные вплоть до потерянных, то есть отправить обратно сегмент с полем подтверждения, равным 2000.

Наконец, обратите внимание, что сервер может подтверждать не только повторно отправленные данные, но и любые предыдущие данные, которые были получены правильно. В этом случае сервер получил повторно отправленный второй сегмент TCP (данные с порядковыми номерами 20002999), и сервер уже получил третий сегмент TCP (данные с номерами 30003999). Следующее поле подтверждения сервера подтверждает данные в обоих этих сегментах с полем подтверждения, равным 4000.

Управление потоком с использованием окон

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

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

Начнем с первого сегмента, отправленного сервером на ПК. Поле Acknowledgment должно быть вам знакомо: оно сообщает ПК, что сервер ожидает следующий сегмент с порядковым номером 1000. Новое поле, поле окна, установлено на 3000. Поскольку сегмент передается на ПК, это значение сообщает ПК, что ПК может послать не более 3000 байтов по этому соединению до получения подтверждения. Итак, как показано слева, ПК понимает, что может отправлять только 3000 байтов, и прекращает отправку, ожидая подтверждения, после отправки трех 1000-байтовых сегментов TCP.

Продолжая пример, сервер не только подтверждает получение данных (без потерь), но и решает немного увеличить размер окна. Обратите внимание, что второе сообщение, идущее справа налево на рисунке, на этот раз с окном 4000. Как только ПК получает этот сегмент TCP, ПК понимает, что он может отправить еще 4000 байтов (окно немного больше, чем предыдущее значение).

Обратите внимание, что хотя на последних нескольких рисунках показаны примеры с целью объяснения того, как работают механизмы, из этих примеров может сложиться впечатление, что TCP заставляет хосты сидеть и долго ждать подтверждения. TCP не хочет заставлять хост-отправитель ждать отправки данных. Например, если подтверждение получено до того, как окно будет исчерпано, начинается новое окно, и отправитель продолжает отправлять данные до тех пор, пока текущее окно не будет исчерпано. Часто в сети, где мало проблем, мало потерянных сегментов и небольшая перегрузка, окна TCP остаются относительно большими, а узлы редко ждут отправки.

Полный курс по Сетевым Технологиям

В курсе тебя ждет концентрат ТОП 15 навыков, которые обязан знать ведущий инженер или senior Network Operation Engineer

Источник

Tcp pacing что это

1. Клиент, который намеревается установить соединение, посылает серверу сегмент с номером последовательности и флагом SYN.

Сервер получает сегмент, запоминает номер последовательности и пытается создать сокет (буферы и управляющие структуры памяти) для обслуживания нового клиента;

В случае успеха сервер посылает клиенту сегмент с номером последовательности и флагами SYN и ACK, и переходит в состояние SYN-RECEIVED;

2. Если клиент получает сегмент с флагом SYN, то он запоминает номер последовательности и посылает сегмент с флагом ACK.

Если он одновременно получает и флаг ACK (что обычно и происходит), то он переходит в состояние ESTABLISHED;

Если клиент получает сегмент с флагом RST, то он прекращает попытки соединиться;

Если клиент не получает ответа в течение 10 секунд, то он повторяет процесс соединения заново.

3. Если сервер в состоянии SYN-RECEIVED получает сегмент с флагом ACK, то он переходит в состояние ESTABLISHED.

В противном случае после тайм-аута он закрывает сокет и переходит в состояние CLOSED.

Процесс называется «трёхэтапным рукопожатием» (англ. three way handshake), так как несмотря на то что возможен процесс установления соединения с использованием четырёх сегментов (SYN в сторону сервера, ACK в сторону клиента, SYN в сторону клиента, ACK в сторону сервера), на практике для экономии времени используется три сегмента.

Источник

Что такое TCP и как он работает?

Протокол управления передачей (TCP) является одним из самых важных протоколов пакета Internet Protocols. Это наиболее широко используемый протокол для передачи данных в сети связи, такой как Интернет.

Длина заголовка TCP составляет минимум 20 байтов и максимум 60 байт.

Адресация

Связь TCP между двумя удаленными хостами выполняется с помощью номеров портов (TSAP). Номера портов могут варьироваться от 0 до 65535, которые делятся как:

Управление подключениями

Связь TCP работает в модели Server / Client. Клиент инициирует соединение, и сервер либо принимает, либо отклоняет его. Для управления подключением используется трехстороннее связывание.

Установка соединения

Клиент инициирует соединение и отправляет сегмент с порядковым номером. Сервер подтверждает это со своим собственным порядковым номером и ACK сегмента клиента, который является еще одним номером последовательности клиентов. Клиент после получения ACK своего сегмента отправляет подтверждение ответа сервера.

Любой из серверов и клиентов может отправлять сегмент TCP с флагом FIN, установленным в 1. Когда принимающая сторона отвечает на это посредством ACKnowlinging FIN, это направление связи TCP закрывается и соединение освобождается.

Управление полосой пропускания

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

Например, клиент использует размер окна 2 и отправляет 2 байта данных. Когда подтверждение этого сегмента получено, размер окна удваивается до 4, а следующий отправленный сегмент отправляется длиной 4 байта данных. Когда получено подтверждение 4-байтового сегмента данных, клиент устанавливает размер окна 8 и т. Д.

Если упущено подтверждение, то есть данные, потерянные в транзитной сети или полученные NACK, размер окна уменьшается до половины, а медленная начальная фаза начинается снова.

Контроль ошибок и контроль потока

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

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

Мультиплексирование

Способ объединения двух или более потоков данных в один сеанс называется мультиплексированием. Когда клиент TCP инициализирует соединение с сервером, он всегда ссылается на четко определенный номер порта, который указывает на процесс приложения. Сам клиент использует случайный номер порта из частных пулов номеров портов.

Используя TCP Multiplexing, клиент может взаимодействовать с несколькими различными процессами приложения за один сеанс. Например, клиент запрашивает веб-страницу, которая, в свою очередь, содержит различные типы данных (HTTP, SMTP, FTP и т. Д.), Тайм-аут сеанса TCP увеличивается, и сеанс остается открытым на более длительное время, так что накладные расходы на трехстороннюю рукопожатие могут избегать.

Это позволяет клиентской системе получать несколько соединений по одному виртуальному соединению. Эти виртуальные соединения не подходят для серверов, если тайм-аут слишком длинный.

Контроль перегрузок

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

Управление таймером

TCP использует различные типы таймеров для управления и управления различными задачами:

Таймер сохранения:

Таймер повторной передачи:

Постоянный таймер:

Timed-Wait:

Восстановление после аварий

TCP — очень надежный протокол. Он предоставляет порядковый номер для каждого байта, отправленного в сегменте. Он обеспечивает механизм обратной связи, т.е. когда хост получает пакет, он привязан к ACK, чтобы ожидал пакет, имеющий следующий порядковый номер (если он не является последним сегментом).

Когда TCP-сервер прерывает связь в середине и перезапускает его процесс, он отправляет трансляцию TPDU всем своим хостам. Затем хосты могут отправить последний сегмент данных, который никогда не был непризнан и продолжен.

Источник

Внутренние механизмы ТСР, влияющие на скорость загрузки: часть 1

Ускорение каких-либо процессов невозможно без детального представления их внутреннего устройства. Ускорение интернета невозможно без понимания (и соответствующей настройки) основополагающих протоколов — IP и TCP. Давайте разбираться с особенностями протоколов, влияющих на скорость интернета.

IP (Internet Protocol) обеспечивает маршрутизацию между хостами и адресацию. TCP (Transmission Control Protocol) обеспечивает абстракцию, в которой сеть надежно работает по ненадежному по своей сути каналу.

Протоколы TCP/IP были предложены Винтом Серфом и Бобом Каном в статье «Протокол связи для сети на основе пакетов», опубликованной в 1974 году. Исходное предложение, зарегистрированное как RFC 675, было несколько раз отредактировано и в 1981 году 4-я версия спецификации TCP/IP была опубликована как два разных RFC:

TCP обеспечивает нужную абстракцию сетевых соединений, чтобы приложениям не пришлось решать различные связанные с этим задачи, такие как: повторная передача потерянных данных, доставка данных в определенном порядке, целостность данных и тому подобное. Когда вы работаете с потоком TCP, вы знаете, что отправленные байты будут идентичны полученным, и что они придут в одинаковом порядке. Можно сказать, что TCP больше «заточен» на корректность доставки данных, а не на скорость. Этот факт создает ряд проблем, когда дело доходит до оптимизации производительности сайтов.

Стандарт НТТР не требует использования именно TCP как транспортного протокола. Если мы захотим, мы можем передавать НТТР через датаграммный сокет (UDP – User Datagram Protocol) или через любой другой. Но на практике весь НТТР трафик передается через TCP, благодаря удобству последнего.

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

Тройное рукопожатие

Все TCP-соединения начинаются с тройного рукопожатия (рис. 1). До того как клиент и сервер могут обменяться любыми данными приложения, они должны «договориться» о начальном числе последовательности пакетов, а также о ряде других переменных, связанных с этим соединением. Числа последовательностей выбираются случайно на обоих сторонах ради безопасности.

Клиент выбирает случайное число Х и отправляет SYN-пакет, который может также содержать дополнительные флаги TCP и значения опций.

SYN ACK

Сервер выбирает свое собственное случайное число Y, прибавляет 1 к значению Х, добавляет свои флаги и опции и отправляет ответ.

Клиент прибавляет 1 к значениям Х и Y и завершает хэндшейк, отправляя АСК-пакет.

Рис. 1. Тройное рукопожатие.

После того как хэндшейк совершен, может быть начат обмен данными. Клиент может отправить пакет данных сразу после АСК-пакета, сервер должен дождаться АСК-пакета, чтобы начать отправлять данные. Этот процесс происходит при каждом TCP-соединении и представляет серьезную сложность плане производительности сайтов. Ведь каждое новое соединение означает некоторую сетевую задержку.

Например, если клиент в Нью-Йорке, сервер – в Лондоне, и мы создаем новое TCP-соединение, это займет 56 миллисекунд. 28 миллисекунд, чтобы пакет прошел в одном направлении и столько же, чтобы вернуться в Нью-Йорк. Ширина канала не играет здесь никакой роли. Создание TCP-соединений оказывается «дорогим удовольствием», поэтому повторное использование соединений является важной возможностью оптимизации любых приложений, работающих по TCP.

TCP Fast Open (TFO)

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

TCP Fast Open (TFO) – это механизм, который позволяет снизить задержку за счет того, что позволяет отправку данных внутри SYN-пакета. Однако и у него есть свои ограничения: в частности, на максимальный размер данных внутри SYN-пакета. Кроме того, только некоторые типы HTTP-запросов могут использовать TFO, и это работает только для повторных соединений, поскольку использует cookie-файл.

Использование TFO требует явной поддержки этого механизма на клиенте, сервере и в приложении. Это работает на сервере с ядром Linux версии 3.7 и выше и с совместимым клиентом (Linux, iOS9 и выше, OSX 10.11 и выше), а также потребуется включить соответствующие флаги сокетов внутри приложения.

Специалисты компании Google определили, что TFO может снизить сетевую задержку при HTTP-запросах на 15%, ускорить загрузку страниц на 10% в среднем и в отдельных случаях – до 40%.

Контроль за перегрузкой

В начале 1984 года Джон Нейгл описал состояние сети, названное им как «коллапс перегрузки», которое может сформироваться в любой сети, где ширина каналов между узлами неодинакова.

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

Нейгл показал, что коллапс перегрузки не представлял в то время проблемы для ARPANETN, поскольку у узлов была одинаковая ширина каналов, а у бэкбона (высокоскоростной магистрали) была избыточная пропускная способность. Однако это уже давно не так в современном интернете. Еще в 1986 году, когда число узлов в сети превысило 5000, произошла серия коллапсов перегрузки. В некоторых случаях это привело к тому, что скорость работы сети падала в 1000 раз, что означало фактическую неработоспособность.

Чтобы справиться с этой проблемой, в TCP были применены несколько механизмов: контроль потока, контроль перегрузки, предотвращение перегрузки. Они определяли скорость, с которой данные могут передаваться в обоих направлениях.

Контроль потока

Контроль потока предотвращает отправку слишком большого количества данных получателю, которые он не сможет обработать. Чтобы этого не происходило, каждая сторона TCP-соединения сообщает размер доступного места в буфере для поступающих данных. Этот параметр — «окно приема» (receive window – rwnd).

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

Если по каким-то причинам одна сторона не может справиться с поступающим потоком данных, она должна сообщить уменьшенное значение своего окна приема. Если окно приема достигает значения 0, это служит сигналом отправителю, что не нужно более отправлять данные, пока буфер получателя не будет очищен на уровне приложения. Эта последовательность повторяется постоянно в каждом TCP-соединении: каждый АСК-пакет несет в себе свежее значение rwnd для обеих сторон, позволяя им динамически корректировать скорость потока данных в соответствии с возможностями получателя и отправителя.

Рис. 2. Передача значения окна приема.

Масштабирование окна (RFC 1323)

Исходная спецификация TCP ограничивала 16-ю битами размер передаваемого значения окна приема. Это серьезно ограничило его сверху, поскольку окно приема не могло быть более 2^16 или 65 535 байт. Оказалось, что это зачастую недостаточно для оптимальной производительности, особенно в сетях с большим «произведением ширины канала на задержку» (BDP – bandwidth-delay product).

Чтобы справиться с этой проблемой в RFC 1323 была введена опция масштабирования TCP-окна, которая позволяла увеличить размер окна приема с 65 535 байт до 1 гигабайта. Параметр масштабирования окна передается при тройном рукопожатии и представляет количество бит для сдвига влево 16-битного размера окна приема в следующих АСК-пакетах.

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

В следующей части мы разберемся, что такое TCP Slow Start, как оптимизировать скорость передачи данных и увеличить начальное окно, а также соберем все рекомендации по оптимизации TCP/IP стека воедино.

Источник

Reproducing Network Research

network systems experiments made accessible, runnable, and reproducible

CS244 ’13: TCP Pacing and Buffer Sizing

Team: Antonin Bas and Diego Pontoriero

Sources:

Introduction

Network traffic is inherently bursty. As a result, all network switches have buffer queues that absorb additional packets that arrive during traffic bursts. The buffers then drain during traffic lulls, keeping average utilization of outgoing links high and causing fewer packets to be dropped.

One open question in the networking community is whether evenly spacing traffic flows, or pacing, can decrease burstiness and allow for lower delays, better throughput, and smaller required queue sizes. In Understanding the Performance of TCP Pacing (Aggarwal et. al., 1999) the authors investigated the impact of modifying TCP to evenly space packets throughout the duration of the round-trip-time (RTT). Using a simulated network consisting of clients and servers communicating over a single bottleneck link, the authors found that for a single flow, pacing increases throughput compared to unpaced TCP. However, when 50 clients communicated with 50 servers concurrently, the authors observed that pacing actually caused lower throughput due to a synchronizing effect on all of the flows’ congestion control algorithms: since the flows increase their congestion windows uniformly, they experience congestion events at roughly the same time and enter multiplicative decrease. In aggregate this causes the total throughput to oscillate widely. In contrast, when flows are bursty, each flow experiences a congestion event at a random time, so synchronized drops in throughput do not occur. This surprising result implied that for real-world networks pacing was not preferable to existing, bursty implementations. Another interesting observation the authors make is that TCP Pacing leads to greater fairness among flows sharing a bottleneck link: intuitively when flows are less bursty there is lower probability of one lucky flow “grabbing” a larger fraction of the congestion window.

Though buffers are a necessary component of a network with bursty traffic, large buffers can increase latency dramatically when they are full. In Sizing Routing Buffers (Appenzeller et. al. 2004) the authors propose that the popular rule of thumb for sizing buffers on switches, known as the “bandwidth-delay product” rule, is overly conservative for links with a large number of flows. The motivation for the bandwidth-delay product is that the buffer should be large enough to keep the output link busy when a sender experiences a congestion event and temporarily stops sending packets as it applies multiplicative decrease to its congestion window. In the paper the authors use a statistical approach to show that when many flows are present, the buffer size can be reduced by a factor of the square root of the number of flows and still have high expected utilization and throughput.

In this blog post we explore the above concepts in two ways. First, we attempt to reproduce the results seen by Aggarwal et. al for a single flow and multiple flows, investigating both cumulative throughput and fairness. Since our kernel patch can only be completely enabled or disabled we were unable to reproduce the section examining the interaction of pacing and non-paced flows. Second, we investigate whether pacing has any impact on the Appenzeller et. al.’s “revised rule of thumb” for switch buffer sizing. We provide all of the code and details describing our experimental setup for anyone to verify and expand upon.

Simulation Environment

Our simulation is conducted using Mininet, an open-source network simulation package. We ran all of our simulations on a c1.xlarge Amazon EC2 instance. While the authors used a different simulation platform, ns2, we chose Mininet for two reasons. First, it was the only platform with which we had any experience and it seemed well-adapted to the paper’s experiments, which did not require high cumulative bandwidth. Second, we thought it would be interesting to compare the two platforms and see if we observed the same behaviour with both. In particular, ns2 is a virtual time simulator, whereas Mininet is a real-time emulator, and clearly time is the key differentiator between paced and unpaced flows.

You can view and download the code used for the simulation here. The README contains instructions for setting up the correct simulation environment.

Simulation Topology

As stated above, the results in Aggarwal et. al. were generated using an ns2 simulation. We tried to reproduce the ns2 topology as exactly as possible in Mininet, but we had to make some tradeoffs. First, because of Mininet’s scalability issues, we believe it may be safer to run experiments in a topology with 5 sender-receiver pairs each running 10 flows, rather than in a topology with 50 sender-receiver pairs each running one flow. Similarly, we had to reduce all of the bandwidth values, since Mininet performs poorly when the cumulative bandwidth exceeds 3Gbps. Second, because Mininet relies on netem to emulate the network, a packet is only removed from a switch buffer once it has left the “link” (or rather the succession of downstream buffers which in Mininet, and also probably in the original ns2 topology, are replaced by a high-delay link). Accordingly, we had to increase the bottleneck router capacity to obtain graphs that are comparable to the paper using the following formula: B_new = B_old + link_delay * link_rate.

Modified Linux Kernel

The standard Linux kernel does not contain support for TCP pacing. We adapted and updated an old patch (see Acknowledgments below) to work with the 3.5 kernel, and solved some serious bugs with the original implementation. Instructions for installing the patch are included in the simulation code’s README.

When enabled, the new code paces TCP flows by constraining the TCP output engine so that the packets in the congestion window are spread as evenly as possible across the estimated round-trip-time (RTT). Compared to the original paper, our implementation uses the same RTT estimation as the main output engine rather than a separate timer. We also enable pacing on both sender and receiver sides rather than just the sender. We do not believe that either difference results in a significant deviation in behavior.

Running the Simulation

Results

TCP Pacing

Below we show Figures 3 and 4 in the TCP Pacing paper, followed by the corresponding results produced by our simulation. They represent a single flow between one sender-receiver pair.

As expected, with a single flow, the cumulative throughput, as measured at the bottleneck router, increases more quickly for TCP Pacing than for NewReno. As observed in the paper, pacing achieves better performance than Reno in the initial period. This is because during the slow-start phase the first loss occurs later for the paced flow, which allows it to get ahead. However, our simulation results differ from the paper in two ways. First, we have not observed as large a difference between the two cumulative throughputs as shown in the paper: in our simulation NewReno slow-start incurs its first packet loss later than in the paper. This is probably due to the fact that in our topology the bottleneck router can handle more burstiness; as explained above, because of netem’s queue management, we had to use a larger queue to obtain similar results. The second difference from the paper is that our congestion window sawtooths for NewReno exhibit decreasing slopes as RTTs increase due to the queue on the bottleneck link becoming full, as one would expect. Pacing does not decrease as much in slope. Interestingly, in the paper there is no clear difference between NewReno and Pacing in this regard.

One additional observation is that in the paper, both flows timeout after the initial slow-start and set their congestion window to 0 before entering slow-start again. On the other hand, in our experiment both flows enter fast recovery. One potential explanation is that the paper (written in 2000 and using ns2) used a slightly different congestion recovery algorithm, which may explain the larger gap in cumulative bandwidths in their results compared to ours.

Below are Figures 6 and 7 from the TCP Pacing paper, followed by corresponding results from our simulation. They represent multiple flows (50) spread between 5 sender-receiver pairs.

For both graphs, our results differ substantially from the paper’s: the cumulative throughput plot is much smoother than in the paper and our fairness plot does not show any improvement when pacing is on. We are very confident in our Pacing implementation, so the explanation must come from elsewhere. Our intuition tells us that this is probably due to a desynchronization of the flows in Mininet. Because ns2 is a simulator and uses virtual time, if all the flows start at the same time and are paced they will be very synchronized, at least during the slow-start phase. In Mininet flows are started sequentially, and the nondeterministic nature of the emulator (it is subject to kernel scheduling and competing processes on the host machine) certainly does not favor synchronization. The method we use to evaluate each flow’s cumulative throughput may also be at cause. Because we initiate several flows on the same host, we cannot measure the total number of bytes sent at an interface (as we are doing for total throughput) but use the tcpprobe log instead, which may be slightly inaccurate.

In most cases, pacing does seem to improve fairness a little during the slow-start phase. Still, there is much variability from one simulation to the next and it is hard to deduce anything significant from the graphs.

Buffer Sizing

To evaluate the impact of pacing on minimum buffer size we used a previous experiment that we had developed for this purpose. Running the experiment with both pacing enabled and disabled resulted in the following plot:

According to this graph, pacing increases the minimum required buffer size. While this size is still below the “revisited rule of thumb”, it can be significantly above the minimum size required for regular TCP NewReno (e.g. for 100 flows). This could be explained by an increased synchronization of the flows, making statistical multiplexing less efficient (higher variability in the sum of all congestion windows). Perhaps 100 flows is too large to have synchronization between flows with TCP NewReno, even if the RTT is the same, but not large enough to avoid synchronization when flows are paced. However, this would be in contradiction with the paper, which claims that in steady state, pacing is more likely to have a de-synchronization effect.

Indeed, the authors claim that in steady state, because of the de-synchronization, throughput is higher with TCP Pacing (section V.B.2). In the experimental setup they use, the delay-bandwidth product is 1250 packets, whereas the buffer size is 312 packets. According to the revised rule of thumb, this amount of buffering should be sufficient since there are 50 flows (requiring 180 packets), meaning that the bottleneck link should never be under-utilized. Our experimental results (PA2) suggest that with regular TCP (CUBIC or Reno) the amount of buffering required is actually even smaller than that. For a similar setup–long iperf flows and seemingly similar RTT and bottleneck bandwidths, with a delay-bandwidth product of 1180 packets instead of 1250 packets–less than 100 packets of buffering was required for regular TCP, as shown in the above graph. This number was even smaller for the real hardware topology, even for flows with the same RTT. It’s impossible to achieve greater than 100% throughput, so how can throughput be better with paced TCP than with regular TCP Reno? It seems there is some form of contradiction between our buffer-sizing experiment’s conclusions and the article’s claims. We believe this warrants further exploration in future work.

Conclusions

In this blog post we have presented two papers related to TCP flow performance and recreated several experiments from those papers. We provide the source code and instructions necessary to reproduce these results on a commodity Amazon EC2 virtual machine.

Though we were able to closely match the TCP Pacing paper’s results for a single flow, our results for multiple flows sharing a bottleneck link did not match. We believe this is due to the random variability in the Mininet environment as compared to ns2. However, we also argue that this more realistically reflects real-world environments, potentially diminishing the authors’ argument that Pacing is not beneficial for widespread use.

To further test this, we investigated the impact of pacing on the “revised rule of thumb” for router buffer sizing. Surprisingly, we found that pacing requires larger buffers than regular TCP Reno for certain numbers of flows. We believe this is due to slight synchronization between paced flows at these levels. For large numbers of flows, however, the difference between pacing and Reno becomes negligible, as one would expect.

Acknowledgments

The Linux kernel modification for TCP pacing is based on a freely distributed patch created by Daniele Lacamera and released under the GPL. The original patch and more information can be found at the project website.

The buffer sizing experiment code is based on starter code developed for Stanford CS244 (Winter 2013) by the Professors and TAs of that class.

Источник