Кратко

  • RFC 3148 не определял универсальное число для пропускной способности сети. Bulk Transport Capacity (BTC) трактовалась как семейство эмпирических измерений, для которых нужно описать транспортное поведение.
  • Характер потерь, тайм-ауты повторной передачи и ритм подтверждений TCP помогают объяснить расхождение скоростей, но один тестовый поток не позволяет судить обо всех пользователях и приложениях.

Число казалось проще эксперимента

Представим два узла, передающих большой файл по одному маршруту. Оба теста стремятся заполнить одно и то же узкое место и делят объём полезных данных на прошедшее время. Результат в обоих случаях — бит в секунду. Но один алгоритм управления перегрузкой может быстро восстановиться после серии потерь, а другой — потерять ритм подтверждений и ждать тайм-аута повторной передачи. Маршрут не изменился, а измеренная скорость — изменилась.

Это не ошибка арифметики. Именно эту проблему RFC 3148 хотел сделать заметной. Опубликованный в июле 2001 года информационный RFC «A Framework for Defining Empirical Bulk Transfer Capacity Metrics» описывает BTC как долгосрочную среднюю скорость одного транспортного соединения, учитывающего перегрузку, обычно TCP. Базовая величина проста: число уникальных битов данных, делённое на прошедшее время. Однако за простой формулой стоят решения реализации.

Слово «ёмкость» наводит на мысль о неизменном свойстве линии. RFC 3148 осторожнее: интуитивной отправной точкой служит долгосрочная скорость идеальной реализации TCP на некотором пути. Но спецификации IETF допускают несколько алгоритмов управления перегрузкой и оставляют свободу внутри каждого. Если разрешённые варианты дают несопоставимые результаты, фраза «BTC этого пути» сама по себе не определяет значение — нужно указать методику.

Совместимый TCP — не неизменный измерительный прибор

Транспортные стандарты задают общее поведение, но не каждый нюанс реализации. Например, RFC 5681 описывает управление перегрузкой TCP и всё же оставляет варианты, важные для измерения. Поэтому RFC 3148 требует, чтобы каждая методика BTC указывала, как растёт окно перегрузки, что происходит у порога slow start, какой алгоритм восстановления после потерь используется, как выбирается размер сегмента, как работает таймер повторной передачи и как настраиваются и считываются измерительные часы.

Это не косметические параметры. Скорость отправителя зависит от подтверждений, возвращающихся по пути. Потеря может вызвать быструю повторную передачу и восстановление, а может заставить отправителя ждать таймер. Восстановление SACK или NewReno, тайм-аут, буферы отправителя, окно приёма и максимальный размер сегмента способны изменить объём данных, переданный одним потоком за интервал. Эти механизмы описаны в RFC 5681, RFC 6298, RFC 2018, RFC 6582 и RFC 6675. Наличие спецификаций не делает все реализации одинаковыми: выбранное поведение становится частью смысла результата.

RFC 3148 отличает более узкую «Congestion Avoidance Capacity» от полной оценки BTC. Узкая величина исключает периоды тайм-аута повторной передачи и slow start. Она может описывать устойчивый режим предотвращения перегрузки, но при этом пропускать восстановление, значимое для настоящей крупной передачи. Смысл не в том, что один показатель всегда лучше, а в том, что название и число не должны скрывать включённое или исключённое поведение.

Сохранять данные, объясняющие расхождение

Заголовочная скорость не объясняет, почему две методики разошлись. RFC 3148 рекомендует собирать вспомогательные показатели или достаточно исходных данных — например, трассу сегментов, — чтобы получить их позднее. Среди возможных наблюдений: серии потерь, переупорядочивание пакетов, тайм-ауты, динамика окна перегрузки, сохранение ритма подтверждений, потери и очереди на тестовом узле, размер сегмента и нагрузка на обратном пути.

Ритм подтверждений — наглядный пример. TCP часто отправляет новые данные в ответ на подтверждения уже доставленных данных. Если этот ритм нарушен, тайм-аут и восстановление через slow start могут занять время, которого не видно в оценке устойчивой скорости. Поэтому две методики могут показать разные значения, по-разному реагируя на одни и те же потери. Трасса позволяет исследовать причину, но сама по себе не доказывает вину конкретного маршрутизатора, очереди или оператора.

Такой подход согласуется с измерительной дисциплиной RFC 2330, который отделяет точное определение метрики от способа измерения и требует учитывать неопределённость и ошибки. Более поздние RFC 5166 об оценке алгоритмов управления перегрузкой и RFC 6349 о тестировании пропускной способности TCP дают смежный контекст. Они не превращают RFC 3148 в единый универсальный тест и не подтверждают, что его применял какой-либо конкретный оператор.

В RFC 3148 есть и тонкое экономическое предостережение: нелинейное поведение управления перегрузкой означает, что при некоторых условиях повышение скорости линии может снизить пропускную способность TCP/BTC. Это возможный эффект и вопрос для исследования, а не измеренный инцидент, общее правило для модернизации сети или доказательство того, что увеличение полосы обычно вредит пользователям. Вывод практический: при изменении числа сначала сохраните методику и наблюдения за путём, а уже затем делайте коммерческие выводы.

Сам тест занимает сеть

BTC измеряют значительной передачей данных, а не несколькими пассивными наблюдениями. Тест намеренно стремится заполнить узкое место. RFC 3148 отмечает, что некоторые методики могут использовать не обычные TCP-пакеты и выглядеть для сетевых операторов как отказ в обслуживании. Поэтому он рекомендует согласовывать время, объём и частоту измерений. Документ также предупреждает, что тестовый трафик могут распознать и обрабатывать иначе либо исказить результат внедрением похожих пакетов.

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

Что можно заключить из одного результата

Это отличается от близкой темы RFC 3133. Он определяет направленные коэффициенты доставки кадров Frame Relay и предупреждает: хороший показатель на канальном уровне может сочетаться с плохой работой приложения, если потеря небольшого подтверждения вызывает намного больше повторных передач. Это конкретный механизм учёта доставки. RFC 3148 задаёт другой вопрос: что делает сопоставимыми две оценки крупной передачи по одному потоку, если допустимые транспортные методы могут вести себя по-разному?

Ответ — методическая дисциплина: описать транспортное поведение, сохранить дополнительные данные, проверить, не стал ли сам тестовый узел узким местом, по возможности отделить влияние прямого и обратного направлений и повторить эксперимент в заданных условиях. Тогда результат поддерживает ограниченное утверждение: указанная методика передала такой объём уникальных данных по наблюдавшемуся пути за этот интервал.

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

Исторический вклад RFC 3148 невелик, но устойчив: он не позволил одной метке стереть решения, встроенные в измерительный прибор. Заголовочное число сохранилось, но методика должна идти вместе с ним.

В качестве интерпретационной рамки я обращаюсь к записке Lu Heng № 64 о минимальной начальной спецификации и локальном выборе, а также к записке № 20 о различии формальных описаний и наблюдаемой реальности. Это редакционные ориентиры, а не утверждения авторов RFC 3148.

Источники

  1. RFC 3148 — A Framework for Defining Empirical Bulk Transfer Capacity Metrics
  2. Запись RFC 3148 в RFC Editor
  3. RFC 2330 — Framework for IP Performance Metrics
  4. RFC 3133 — Terminology for Frame Relay Benchmarking
  5. RFC 5166 — Metrics for the Evaluation of Congestion Control Algorithms
  6. RFC 6349 — Framework for TCP Throughput Testing
  7. RFC 5681 — TCP Congestion Control
  8. RFC 6298 — Computing TCP's Retransmission Timer
  9. RFC 2018 — TCP Selective Acknowledgment Options
  10. RFC 6582 — The NewReno Modification to TCP's Fast Recovery Algorithm
  11. RFC 6675 — A Conservative Loss Recovery Algorithm Based on Selective Acknowledgment
  12. Lu Heng, записка 64 — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  13. Lu Heng, записка 20 — On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile