RFC 8239 | Методология сравнительного анализа центра обработки данных

RFC 8239 | Методология сравнительного анализа центра обработки данных

Аннотация

Цель данного информационного документа — установить методологию тестирования и оценки измерения для физического сетевого оборудования в центре обработки данных. RFC 8238 является обязательным условием для этого документа, так как он содержит терминологию, которая считается нормативной. Многие из этих терминов и методов могут быть применимы за пределами данного документа, поскольку технологии, изначально применяемые в центре обработки данных, развернуты в других местах.

Скачать оригинальный документ на английском языке RFC 8239 PDF

 

Оглавление

1. Введение
1.1. Требования Языка
1.2. Методология Формат и рекомендации по повторяемости
2. Линейное тестирование
2.1. Задача
2.2. Методология
2.3. Формат отчетности
3. Буферное тестирование
3.1. Задача
3.2. Методология
3.3. Формат отчетности
4. Тестирование микропакетов
4.1. Задача
4.2. Методология
4.3. Формат отчетности
5. Блокировка заголовка строки (HOLB)
5.1. Задача
5.2. Методология
5.3. Формат отчетности
6. В приведенном трафике с отслеживанием состояния и без сохранения состояния
6.1. Задача
6.2. Методология
6.3. Формат отчетности
7. Вопросы безопасности
8. Соображения IANA
9. Ссылки
9.1. Нормативные ссылки
9.2. Информационные ссылки
Благодарности
Адреса авторов

 

1. Введение

Схемы трафика в дата-центре неоднородны и постоянно меняются. Они продиктованы характером и разнообразием приложений, используемых в центре обработки данных. Это могут быть в основном потоки трафика восток-запад (сервер-сервер внутри центра обработки данных) в одном центре обработки данных и север-юг (от центра обработки данных к серверу) в другом, в то время как другие могут объединять оба. Схемы трафика могут быть импульсными по своей природе и содержать потоки «многие к одному», «многие ко многим» или «один ко многим». Каждый поток может также быть маленьким и чувствительным к задержке или большим и чувствительным к пропускной способности, в то же время содержащий смесь трафика UDP и TCP. Все они могут сосуществовать в одном кластере и проходить через одно сетевое устройство одновременно. Бенчмаркинг-тесты для сетевых устройств уже давно используют [RFC1242], [RFC2432], [RFC2544], [RFC2889] и [RFC3918], которые в основном были сосредоточены вокруг различных атрибутов задержки и пропускной способности [RFC2889] тестируемого устройства (DUT — Device Under Test) бенчмаркинг. Эти стандарты хороши при измерении теоретической пропускной способности, скорости пересылки и задержки в условиях тестирования; однако они не представляют реальные шаблоны трафика, которые могут повлиять на эти сетевые устройства.

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

  • Высокая плотность портов (48 портов и более)
  • Высокая скорость (в настоящее время до 100 ГБ/с на порт)
  • Высокая пропускная способность (линейная скорость на всех портах для уровня 2 и / или уровня 3)
  • Низкая задержка (в микросекундном или наносекундном диапазоне)
  • Низкий объем буфера (в диапазоне МБ на сетевое устройство)
  • Возможность пересылки уровня 2 и уровня 3 (уровень 3 не является обязательным)

Этот документ предоставляет методологию для сравнения DUT физического оборудования сетевого центра обработки данных, в том числе сценарии перегрузки, анализ буфера коммутатора, микропакеты и блокировку заголовка, а также использование широкого набора условий трафика. [RFC8238] является обязательным условием для этого документа, так как он содержит терминологию, которая считается нормативной.

 

1.1. Требования Языка

Ключевые слова «ОБЯЗАН — MUST», «НЕ ОБЯЗАН — MUST NOT», «ТРЕБУЕТСЯ — REQUIRED», «ДОЛЖЕН — SHALL», «НЕ ДОЛЖЕН — SHALL NOT», «СЛЕДУЕТ — SHOULD», «НЕ СЛЕДУЕТ — SHOULD NOT», «РЕКОМЕНДУЕТСЯ — RECOMMENDED», «НЕ РЕКОМЕНДУЕТСЯ — NOT RECOMMENDED», «ВОЗМОЖЕН — MAY» и «ДОПОЛНИТЕЛЬНО — OPTIONAL» в этом документе интерпретироваться как описано в [RFC2119] [RFC8174].

 

1.2. Методология Формат и рекомендации по повторяемости

Следующий формат используется в разделах 2–6 этого документа:

  • Задача
  • Методология
  • Формат отчетности

Для каждой методики испытаний, описанной в этом документе, очень важно обеспечить повторяемость результатов. Рекомендуется выполнить достаточное количество итераций данного теста и убедиться, что результат соответствует. Это особенно важно в контексте тестов, описанных в разделе 3, поскольку тестирование буферизации исторически было наименее надежным. Количество итераций ДОЛЖНО быть указано в явном виде. Относительное стандартное отклонение ДОЛЖНО быть ниже 10%.

 

2. Линейное тестирование

2.1. Задача

Целью этого теста является предоставление теста «максимальной скорости» для значений производительности для пропускной способности, задержки и дрожания. Он предназначен для предоставления (1) тестов для выполнения и (2) методологии для проверки того, что DUT способно пересылать пакеты со скоростью линии при не перегруженных условиях.

2.2. Методология

Генератор трафика ДОЛЖЕН быть подключен ко всем портам на DUT. ДОЛЖНЫ быть проведены два теста: (1) тест пары портов [RFC2544] [RFC3918] и (2) тест с использованием полноразмерного DUT [RFC2889] [RFC3918].

Во всех тестах частота отправки генератора трафика ДОЛЖНА быть меньше или равна 99,98% от номинального значения скорости линии (без дальнейшей корректировки частей на миллион (PPM) для учета допусков тактовой частоты интерфейса), чтобы обеспечить усиление нагрузки на интерфейс. DUT в приемлемых условиях наихудшего случая (более подробно см. [RFC8238], раздел 5). Результаты тестов с более низкой скоростью МОГУТ предоставляться для лучшего понимания увеличения производительности с точки зрения задержки и дрожания, когда скорость ниже 99,98%. Скорость приема трафика СЛЕДУЕТ регистрировать во время этого теста в процентах от скорости линии.

Тест ДОЛЖЕН предоставлять статистику минимального, среднего и максимального распределения задержки для точно такой же итерации теста.

Тест ДОЛЖЕН предоставлять статистику минимума, среднего и максимума распределения джиттера для точно такой же итерации теста.

В качестве альтернативы, когда генератор трафика не может быть подключен ко всем портам на тестируемом устройстве, тест змеи ДОЛЖЕН использоваться для тестирования скорости линии, исключая задержки и джиттер, поскольку они станут неактуальными. Тест на змею выполняется следующим образом:

  • Подключите первый и последний порт проверяемого устройства к генератору трафика.
  • Подключите, спина к спине и последовательно, все порты между ними: порт 2 к порту 3, порт 4 к порту 5 и т. д., К порту N-2 и порту N-1, где N — общее количество портов DUT.
  • Настройте порт 1 и порт 2 в одной VLAN X, порт 3 и порт 4 в одной VLAN Y и т. д., А также порт N-1 и порт N в той же VLAN Z.

Этот змеиный тест предоставляет возможность проверить скорость линии для уровня 2 и уровня 3 [RFC2544 #] [RFC3918 #] в тех случаях, когда доступен генератор трафика только с двумя портами. Задержка и дрожание не должны рассматриваться для этого теста.

 

2.3. Формат отчетности

Отчет ДОЛЖЕН включать следующее:

  • — Информация о калибровке физического уровня, как определено в [RFC8238], раздел 4.
  • — Количество используемых портов.
  • — Считывание для «пропускной способности, полученной в процентах от пропускной способности», при отправке 99,98% от номинального значения скорости линии на каждый порт для каждого размера пакета от 64 байтов до 9216 байтов. В качестве руководства с идеальным приращением размера пакета в 64 байта между каждой итерацией также часто используются 256-байтовые и 512-байтовые пакеты. Наиболее распространенное упорядочение размера пакета для отчета составляет 64 байта, 128 байтов, 256 байтов, 512 байтов, 1024 байта, 1518 байтов, 4096 байтов, 8000 байтов и 9216 байтов.

Шаблон для тестирования может быть выражен с использованием [RFC6985 #].

  • Пропускная способность должна быть выражена в процентах от общего количества переданных кадров.
  • Отбрасывание пакетов ДОЛЖНО быть выражено как количество пакетов и ДОЛЖНО быть выражено в процентах от скорости линии.
  • Для задержки и дрожания значения выражаются в единицах времени (обычно микросекунды или наносекунды), считывая при размерах пакетов от 64 байтов до 9216 байтов.
  • Для задержки и дрожания укажите минимальные, средние и максимальные значения. Если для сбора минимальных, средних и максимальных значений выполняются разные итерации, это СЛЕДУЕТ указывать в отчете вместе с обоснованием того, почему информация не могла быть собрана в одной и той же итерации теста.
  • Для джиттера РЕКОМЕНДУЕТСЯ гистограмма, описывающая совокупность пакетов, измеренных на задержку или интервалы задержки.
  • Тесты на пропускную способность, задержку и джиттер МОГУТ проводиться как отдельные независимые испытания с надлежащей документацией, представленной в отчете, но ДОЛЖНЫ быть проведены в то же время.
  • Методология предполагает, что DUT имеет по меньшей мере девять портов, поскольку для некоторых методологий требуется девять или более портов.

 

3. Буферное тестирование

3.1. Задача

Целью этого теста является измерение размера буфера проверяемого устройства в типичных / много / многократных условиях. Буферные архитектуры между несколькими DUT могут отличаться и включать в себя выходную буферизацию, разделяемую выходную буферизацию SoC (Switch-on-Chip), входную буферизацию или их комбинацию. Методология тестирования охватывает измерение буфера независимо от архитектуры буфера, используемого в DUT.

3.2. Методология

Генератор трафика ДОЛЖЕН быть подключен ко всем портам на DUT. Методология измерения буферизации для коммутатора центра обработки данных основана на использовании известной перегрузки известного фиксированного размера пакета наряду с измерениями максимального значения задержки. Максимальная задержка будет увеличиваться, пока не произойдет первое отбрасывание пакета. В этот момент максимальное значение задержки будет оставаться постоянным. Это точка перегиба этого изменения максимальной задержки до постоянного значения. ДОЛЖНЫ быть несколько входных портов, принимающих известное количество кадров с известным фиксированным размером, предназначенных для одного и того же выходного порта, чтобы создать известное условие перегрузки. Общее количество пакетов, отправленных с превышенного подпиской порта минус один, умноженное на размер пакета, представляет максимальный размер буфера порта в измеренной точке перегиба.

Обратите внимание, что тесты, описанные в процедурах 1), 2), 3) и 4) в этом разделе, имеют итерации, называемые «первая итерация», «вторая итерация» и «последняя итерация». Идея состоит в том, чтобы показать первые две итерации, чтобы читатель понимал логику того, как продолжать увеличивать итерации. Последняя итерация показывает конечное состояние переменных.

1) Измерьте максимальную эффективность буфера.

  1. Первая итерация: входной порт 1 отправляет 64-байтовые пакеты со скоростью линии на выходной порт 2, в то время как порт 3 отправляет известный низкий объем трафика превышения подписки (рекомендуется 1%) с тем же размером пакета в 64 байта на выходной порт 2. Измерьте значение размера буфера числа кадров, отправленных с порта, отправляющего переписанный трафик до точки перегиба, умноженного на размер кадра.
  2. Вторая итерация: входной порт 1 отправляет 65-байтовые пакеты со скоростью линии на выходной порт 2, в то время как порт 3 отправляет известный низкий объем трафика превышения подписки (рекомендуется 1%) с тем же размером пакета 65 байтов на выходной порт 2. Измерьте значение размера буфера числа кадров, отправленных с порта, отправляющего переписанный трафик до точки перегиба, умноженного на размер кадра.
  3. Последняя итерация: входной порт 1 отправляет пакеты байтов размера B со скоростью линии на выходной порт 2, в то время как порт 3 отправляет известный низкий объем трафика превышения подписки (рекомендуется 1%) с тем же размером пакета B байтов на выходной порт 2 Измерьте значение размера буфера количества кадров, отправленных из порта, отправляющего переписанный трафик до точки перегиба, умноженного на размер кадра.

Когда установлено, что значение B обеспечивает максимальный размер буфера, тогда размер B обеспечивает максимальную эффективность буфера.

2) Измерьте максимальный размер буфера порта.

При фиксированном размере пакета B, как определено в процедуре 1), для фиксированного значения по умолчанию кодовой точки дифференцированной услуги (DSCP) / класса обслуживания (CoS) по умолчанию, равного 0, и для одноадресного трафика выполните следующее:

  1. Первая итерация: скорость входящего порта 1 для исходящего порта 2, в то время как порт 3 отправляет известный низкий объем трафика превышения подписки (рекомендуется 1%) с тем же размером пакета на выходной порт 2. Измерьте значение размера буфера, умножив количество дополнительных кадров, отправленных по размеру кадра.
  2. Вторая итерация: скорость входящего порта 2 для исходящего порта 3, в то время как порт 4 отправляет известный низкий объем трафика превышения подписки (рекомендуется 1%) с тем же размером пакета на выходной порт 3. Измерьте значение размера буфера, умножив количество дополнительных кадров, отправленных по размеру кадра.
  3. Последняя итерация: скорость линии отправки входного порта N-2 на выходной порт N-1, в то время как порт N отправляет известный низкий объем трафика превышения подписки (рекомендуется 1%) с тем же размером пакета на выходной порт N. Измерьте размер буфера значение путем умножения количества дополнительных кадров, отправляемых на размер кадра.

Эта серия тестов МОЖЕТ быть повторена с использованием всех различных значений трафика DSCP / CoS, а затем с использованием многоадресного трафика, чтобы выяснить, есть ли какое-либо влияние DSCP / CoS на размер буфера.

3) Измерьте максимальный размер буфера пары портов.

  1. Первая итерация: скорость входящего порта 1 для входного порта 2, скорость 3 для входного порта 3 на выходной порт 4 и т. д. Входной порт N-1 и порт N будут переподписываться при 1% скорости линии, выходной порт 2 и порт 3 соответственно. Измерьте значение размера буфера, умножив количество дополнительных кадров, отправленных на размер кадра для каждого выходного порта.
  2. Вторая итерация: скорость входящего порта 1 для входного порта 2, скорость 3 для входного порта 3 на выходной порт 4 и т. д. Входной порт N-1 и порт N будут переподписываться при 1% скорости линии, выходной порт 4 и порт 5 соответственно. Измерьте значение размера буфера, умножив количество дополнительных кадров, отправленных на размер кадра для каждого выходного порта.
  3. Последняя итерация: скорость входящего порта 1 для входного порта 2, скорость 3 для входного порта 3 на выходной порт 4 и т. д. Входной порт N-1 и порт N будут переподписывать при 1% скорости линии, выходной порт N- 3 и порт N-2 соответственно. Измерьте значение размера буфера, умножив количество дополнительных кадров, отправленных на размер кадра для каждого выходного порта.

Эта серия испытаний МОЖЕТ быть повторена с использованием всех различных значений трафика DSCP / CoS, а затем с использованием многоадресного трафика.

4) Измерьте максимальный размер буфера DUT с портами многие-к-одному.

  1. Первая итерация: входящие порты 1,2, … N-1 каждая отправляет [(1 / [N-1]) * 99,98] + [1 / [N-1]]% от скорости линии на порт на выходной порт Н.
  2. Вторая итерация: входящие порты 2, … N каждая отправка [(1 / [N-1]) * 99,98] + [1 / [N-1]]% от скорости линии на порт на выходной порт 1.
  3. Последняя итерация: входящие порты N, 1,2 … N-2, каждая отправляющая [(1 / [N-1]) * 99,98] + [1 / [N-1]]% скорости линии на порт для выхода порт N-1.

Эта серия испытаний МОЖЕТ быть повторена с использованием всех различных значений CoS трафика, а затем с использованием многоадресного трафика.

Одноадресный трафик, а затем многоадресный трафик СЛЕДУЕТ использовать для определения доли буфера для документированного выбора тестов. Кроме того, значение CoS для пакетов СЛЕДУЕТ предоставлять для каждой итерации теста, поскольку размер выделения буфера МОЖЕТ различаться в зависимости от значения CoS. РЕКОМЕНДУЕТСЯ, чтобы входные и выходные порты менялись случайным, но задокументированным образом в нескольких тестах, чтобы измерить размер буфера для каждого порта проверяемого устройства.

 

3.3. Формат отчетности

Отчет ДОЛЖЕН включать следующее:

  • Размер пакета, используемый для наиболее эффективного используемого буфера, вместе со значением DSCP / CoS.
  • Максимальный размер буфера порта для каждого порта.
  • Максимальный размер буфера DUT.
  • Размер пакета, используемый в тесте.
  • Сумма переподписки, если отличается от 1%.
  • Количество входных и выходных портов, а также их расположение на DUT.
  • Необходимо указать повторяемость теста: количество итераций одного и того же теста и процент вариации между результатами для каждого из тестов (min, max, avg).

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

Например, для теста с задержкой, в котором измеряется минимальная задержка, процент вариации (PV) минимальной задержки будет указывать, насколько эта величина варьировалась между текущим выполненным тестом и предыдущим.

PV = ((x2-x1) / x1) * 100, где x2 — это минимальное значение задержки в текущем тесте, а x1 — минимальное значение задержки, полученное в предыдущем тесте.

Эта же формула используется для измерения максимального и среднего отклонений.

 

4. Тестирование микропакетов

4.1. Задача

Цель этого теста — найти максимальное количество пакетов, которое DUT может выдержать при различных конфигурациях.

Этот тест предоставляет дополнительную методологию, которая дополняет тесты, описанные в [RFC1242], [RFC2432], [RFC2544], [RFC2889] и [RFC3918].

  • Все посылки должны быть отправлены со 100% интенсивностью. Примечание: «Интенсивность» определена в [RFC8238], раздел 6.1.1.
  • Для этого теста должны использоваться все порты проверяемого устройства.
  • Рекомендуется проверять все порты одновременно.

4.2. Методология

Генератор трафика ДОЛЖЕН быть подключен ко всем портам на DUT. Чтобы вызвать перегрузку, два или более входных порта ДОЛЖНЫ отправлять пакеты пакетов, предназначенных для одного и того же выходного порта. Простейшей из этих настроек будет два входных порта и один выходной порт (от 2 до 1).

Пакет ДОЛЖЕН быть отправлен с интенсивностью (как определено в [RFC8238], раздел 6.1.1), равной 100%, что означает, что пакет пакетов будет отправлен с минимальным межпакетным интервалом. Количество пакетов, содержащихся в пакете, будет пробной переменной и будет увеличиваться до тех пор, пока не будет измерена ненулевая потеря пакетов. Суммарное количество пакетов от всех отправителей будет использоваться для расчета максимального количества микропакетов, которое может выдержать проверяемое устройство.

РЕКОМЕНДУЕТСЯ, чтобы входные и выходные порты менялись в нескольких тестах, чтобы измерить максимальную пропускную способность микровзрыва.

Интенсивность микровзрыва (см. [RFC8238], раздел 6.1.1) МОЖЕТ варьироваться для получения мощности микровзрыва при различных скоростях проникновения.

РЕКОМЕНДУЕТСЯ, чтобы все порты на тестируемом устройстве тестировались одновременно и в различных конфигурациях, чтобы понять все комбинации входных портов, выходных портов и интенсивности.

Примером может быть:

  1. Первая итерация: отправка N-1 входных портов на один выходной порт.
  2. Вторая итерация: отправка N-2 входных портов на два выходных порта.
  3. Последняя итерация: отправка двух входных портов на выходные порты N-2.

4.3. Формат отчетности

Отчет ДОЛЖЕН включать следующее:

  • Максимальное количество пакетов, полученных на входной порт с максимальным размером пакета, полученным с нулевой потерей пакетов.
  • Размер пакета, используемый в тесте.
  • Количество входных и выходных портов, а также их расположение на DUT.
  • Необходимо указать повторяемость теста: количество итераций одного и того же теста и процент вариации между результатами (минимальное, максимальное, среднее).

 

5. Блокировка заголовка строки (HOLB)

5.1. Задача

Блокировка заголовка строки (HOLB — Head-of-Line Blocking) ​​- это явление, ограничивающее производительность, которое возникает, когда пакеты задерживаются первым пакетом, ожидающим передачи в другой выходной порт. Это определено в RFC 2889, раздел 5.5 («Контроль перегруженности»). Этот раздел расширяет RFC 2889 в контексте сравнительного анализа центров обработки данных.

Цель этого теста — понять поведение DUT в сценарии HOLB и измерить потерю пакетов.

Различия между этим тестом HOLB и RFC 2889 # заключаются в следующем:

  • Этот тест HOLB начинается с восьми портов в двух группах по четыре порта в каждой вместо четырех портов (по сравнению с разделом 5.5 RFC 2889).
  • Этот тест HOLB сдвигает все номера портов на один во второй итерации теста; это новое по сравнению с тестом HOLB, описанным в RFC 2889. Номера портов смещения продолжаются до тех пор, пока все порты не станут первыми в группе; цель этого состоит в том, чтобы удостовериться, что все перестановки проверены, чтобы покрыть различия в поведении в SoC DUT.
  • Другой тест в рамках этого теста HOLB расширяет группу портов, так что трафик делится между четырьмя портами вместо двух (25% вместо 50% на порт).
  • В разделе 5.3 перечислены требования, которые дополняют требования, перечисленные в RFC 2889, раздел 5.5.

5.2. Методология

Чтобы вызвать перегрузку в форме HOLB, используются группы из четырех портов. Группа имеет два входных порта и два выходных порта. Первый входной порт ДОЛЖЕН иметь два настроенных потока, каждый из которых направляется на свой выходной порт. Второй входной порт будет заполнен вторым выходным портом путем отправки скорости линии. Цель состоит в том, чтобы измерить, есть ли потери в потоке для первого выходного порта, который не переподписан.

Генератор трафика ДОЛЖЕН быть подключен как минимум к восьми портам на DUT и ДОЛЖЕН быть подключен с использованием всех портов DUT.

Обратите внимание, что тесты, описанные в процедурах 1) и 2) в этом разделе, имеют итерации, называемые «первая итерация», «вторая итерация» и «последняя итерация». Идея состоит в том, чтобы показать первые две итерации, чтобы читатель понимал логику того, как продолжать увеличивать итерации. Последняя итерация показывает конечное состояние переменных.

1) Измерьте две группы с восемью портами DUT.

o Первая итерация: измерение потери пакетов для двух групп с последовательными портами.

Состав первой группы выглядит следующим образом:

Входной порт 1 отправляет 50% трафика на выходной порт 3, а входной порт 1 отправляет 50% трафика на выходной порт 4. Скорость входящей линии 2 для отправки на выходной порт 4. Измерьте величину потери трафика для трафика от входного порта 1. к выходному порту 3.

Состав второй группы выглядит следующим образом:

Входной порт 5 отправляет 50% трафика на выходной порт 7, а входной порт 5 отправляет 50% трафика на выходной порт 8. Скорость входящего порта 6 отправляет на выходной порт 8. Измерьте величину потери трафика для трафика от входного порта 5. к выходному порту 7.

o Вторая итерация: повторите первую итерацию, сдвинув все порты с N на N + 1.

Состав первой группы выглядит следующим образом:

Входной порт 2 отправляет 50% трафика на выходной порт 4, а входной порт 2 отправляет 50% трафика на выходной порт 5. Входная скорость порта 3 для отправки на выходной порт 5. Измерьте величину потери трафика для трафика от входного порта 2. к выходному порту 4.

Состав второй группы выглядит следующим образом:

Входной порт 6 отправляет 50% трафика на выходной порт 8, а входной порт 6 отправляет 50% трафика на выходной порт 9. Входная скорость порта 7 для отправки на выходной порт 9. Измерьте величину потери трафика для трафика от входного порта 6. к выходному порту 8.

o Последняя итерация: когда первый порт первой группы подключен к последнему порту DUT, а последний порт второй группы подключен к седьмому порту DUT.

Измерьте величину потери трафика для трафика от входного порта N до выходного порта 2 и от входного порта 4 до выходного порта 6.

2) Измерьте с помощью N / 4 групп с N портами DUT.

Трафик от входного порта распределяется по четырем выходным портам (100/4 = 25%).

o Первая итерация: разверните, чтобы полностью использовать все порты DUT с шагом четыре. Повторите методологию процедуры 1) со всеми группами портов, которые можно получить на устройстве, и измерьте количество потерь трафика для каждой группы портов.

o Вторая итерация: сдвиг на +1 начала каждого последовательного порта групп портов.

o Последняя итерация: сдвиньте на N-1 начало каждого последовательного порта групп портов и измерьте количество потерь трафика для каждой группы портов.

5.3. Формат отчетности

Для каждого теста отчет ДОЛЖЕН включать следующее:

  • Конфигурация порта, включая количество и расположение входных и выходных портов, расположенных на DUT
  • Если HOLB наблюдался в соответствии с тестом HOLB, описанным в разделе 5
  • Процент потерь трафика
  • Необходимо указать повторяемость теста: количество итераций одного и того же теста и процент вариации между результатами (мин., Макс., Средн.)

6. В приведенном трафике с отслеживанием состояния и без сохранения состояния

6.1. Задача

Цель этого теста — измерить значения полезной пропускной способности TCP [TCP-INCAST] и задержки с сочетанием больших и малых потоков. Тест предназначен для имитации смешанной среды потоков с отслеживанием состояния, которые требуют высокой скорости передачи данных и потоков без сохранения состояния, которые требуют низкой задержки. Потоки с сохранением состояния создаются путем генерации трафика TCP, а потоки без сохранения состояния — с использованием трафика UDP.

6.2. Методология

Чтобы моделировать влияние трафика без сохранения состояния и состояния на DUT, ДОЛЖНЫ быть несколько входных портов, принимающих трафик, предназначенный для того же самого выходного порта. Также МОЖЕТ быть смесь трафика с состоянием и без сохранения состояния, поступающего на один входной порт. Самая простая настройка — два входных порта, принимающих трафик к одному выходному порту.

Один входной порт ДОЛЖЕН поддерживать TCP-соединение через входной порт с приемником, подключенным к выходному порту. Трафик в потоке TCP ДОЛЖЕН быть отправлен с максимальной скоростью, разрешенной генератором трафика. В то же время трафик TCP проходит через DUT, и трафик без сохранения состояния отправляется получателю на тот же выходной порт. Трафик без сохранения состояния ДОЛЖЕН быть микропакетом с интенсивностью 100%.

РЕКОМЕНДУЕТСЯ, чтобы входные и выходные порты менялись в нескольких тестах, чтобы измерить максимальную пропускную способность микропакета.

Интенсивность микровзрыва МОЖЕТ варьироваться для получения мощности микропакета при различных скоростях проникновения.

РЕКОМЕНДУЕТСЯ, чтобы при тестировании использовались все порты на тестируемом устройстве.

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

Например:

Изменение порта трафика с отслеживанием состояния (трафик TCP):

Для этого теста необходимо сгенерировать TCP-трафик. Во время итераций количество выходных портов МОЖЕТ также изменяться.

  1. Первая итерация: один входной порт, принимающий TCP-трафик с состоянием, и один входной порт, принимающий трафик без сохранения состояния, предназначенный для одного выходного порта.
  2. Вторая итерация: два входных порта, принимающих TCP-трафик с отслеживанием состояния, и один входной порт, получающих трафик без сохранения состояния, предназначенный для одного выходного порта.
  3. Последняя итерация: N-2 входных портов, принимающих TCP-трафик с сохранением состояния, и один входной порт, принимающих трафик без сохранения состояния, предназначенных для одного выходного порта.

Изменение порта трафика без сохранения состояния (трафик UDP):

Для этого теста необходимо сгенерировать UDP-трафик. Во время итераций количество выходных портов МОЖЕТ также изменяться.

  1. Первая итерация: один входной порт, принимающий TCP-трафик с состоянием, и один входной порт, принимающий трафик без сохранения состояния, предназначенный для одного выходного порта.
  2. Вторая итерация: один входной порт, принимающий TCP-трафик с сохранением состояния, и два входных порта, принимающие трафик без сохранения состояния, предназначенный для одного выходного порта.
  3. Последняя итерация: один входной порт, принимающий TCP-трафик с сохранением состояния, и N-2 входных порта, принимающие трафик без сохранения состояния, предназначенный для одного выходного порта.

6.3. Формат отчетности

Отчет ДОЛЖЕН включать следующее:

  • Количество входных и выходных портов, а также назначение назначения потока с состоянием или без состояния.
  • Stateful flow goodput — полезная пропускная способность потока с отслеживанием состояния.
  • Задержка потока без сохранения состояния.
  • Необходимо указать повторяемость теста: количество итераций одного и того же теста и процент вариации между результатами (мин., Макс., Средн.).

7. Вопросы безопасности

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

Топология эталонной сети будет независимой тестовой установкой и НЕ ДОЛЖНА подключаться к устройствам, которые могут перенаправлять тестовый трафик в производственную сеть или перенаправлять трафик в сеть управления тестированием.

Кроме того, бенчмаркинг выполняется по принципу «черного ящика», опираясь исключительно на измерения, наблюдаемые вне DUT.

Специальные возможности НЕ ДОЛЖНЫ существовать в DUT специально для целей бенчмаркинга. Любые последствия для безопасности сети, возникающие из-за DUT, ДОЛЖНЫ быть одинаковыми в лабораторных и производственных сетях.

8. Соображения IANA

Этот документ не требует никаких действий IANA.

9. Ссылки

9.1. Нормативные ссылки

[RFC1242] Bradner, S., «Benchmarking Terminology for Network Interconnection Devices», RFC 1242, DOI 10.17487/RFC1242, July 1991, <https://www.rfc-editor.org/info/rfc1242>.

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC2544] Bradner, S. and J. McQuaid, «Benchmarking Methodology for Network Interconnect Devices», RFC 2544, DOI 10.17487/RFC2544, March 1999, <https://www.rfc-editor.org/info/rfc2544>.

[RFC8174] Leiba, B., «Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words», BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8238] Avramov, L. and J. Rapp, «Data Center Benchmarking Terminology», RFC 8238, DOI 10.17487/RFC8238, August 2017, <https://www.rfc-editor.org/info/rfc8238>.

9.2. Информационные ссылки

[RFC2432] Dubray, K., «Terminology for IP Multicast Benchmarking», RFC 2432, DOI 10.17487/RFC2432, October 1998, <https://www.rfc-editor.org/info/rfc2432>.

[RFC2889] Mandeville, R. and J. Perser, «Benchmarking Methodology for LAN Switching Devices», RFC 2889, DOI 10.17487/RFC2889, August 2000, <https://www.rfc-editor.org/info/rfc2889>.

[RFC3918] Stopp, D. and B. Hickman, «Methodology for IP Multicast Benchmarking», RFC 3918, DOI 10.17487/RFC3918, October 2004, <https://www.rfc-editor.org/info/rfc3918>.

[RFC6985] Morton, A., «IMIX Genome: Specification of Variable Packet Sizes for Additional Testing», RFC 6985, DOI 10.17487/RFC6985, July 2013, <https://www.rfc-editor.org/info/rfc6985>.

[TCP-INCAST] Chen, Y., Griffith, R., Zats, D., Joseph, A., and R. Katz, «Understanding TCP Incast and Its Implications for Big Data Workloads», April 2012, <http://yanpeichen.com/professional/usenixLoginIncastReady.pdf>.

Благодарности

Авторы хотели бы поблагодарить Эла Мортона и Скотта Брэднера за их отзывы и обратную связь.

Адреса авторов

Lucien Avramov
Google
1600 Amphitheatre Parkway
Mountain View, CA 94043
United States of America
Email: lucien.avramov@gmail.com

Jacob Rapp
VMware
3401 Hillview Ave.
Palo Alto, CA 94304
United States of America
Email: jhrapp@gmail.com