Кратко

  • RFC 5136 требует указывать для ёмкости протокольный слой, класс пакетов, концы, начало и длительность измерения.
  • Номинальная физическая ёмкость — теоретический верхний предел, а не IP-ресурс, доступный конкретному потоку.
  • IP-ёмкость считает правильно принятые на назначении IP-биты и не доказывает полезность данных для приложения.
  • Type P задаёт популяцию пакетов, поскольку маркировка, очереди, ACL, политика и балансировка меняют обработку.
  • Использование — реально принятый трафик; утилизация — его отношение к так же квалифицированной ёмкости.
  • Доступная ёмкость — незанятая доля в [T,T+I]; для пути берётся минимальный остаток среди звеньев.
  • Narrow link с минимальной ёмкостью и tight link с минимальной доступной ёмкостью могут быть разными.
  • Без T и I результат нельзя безопасно сравнивать или выдавать за текущее состояние.
  • Периодический отбор может синхронизироваться с периодической нагрузкой и многократно подтверждать один сдвиг.
  • Дубликаты, заголовки и повторы занимают сеть, но не обязательно увеличивают уникальные полезные данные.
  • Bulk Transfer Capacity измеряет уникальные данные транспорта с реакцией на перегрузку и не равна IP-величинам RFC 5136.
  • Руководству нужны отдельные квитанции о физической возможности, IP-наблюдении, текущем запасе, договорном праве и результате.

Верхний предел не сообщает остаток

Запись «10 Гбит/с» может точно описывать режим интерфейса. Она не сообщает, сколько корректных IP-бит получит нужный класс между нужными узлами, сколько ресурса уже занято другими источниками и завершится ли приложение вовремя.

RFC 5136 обозначает теоретический физический максимум как NomCap(L). Это верхняя граница и способ отделить физический слой от IP. Значение обычно постоянно, хотя документ приводит динамическое включение спутниковых транспондеров как пример изменения.

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

Подмена происходит ступенчато: «порт способен» превращается в «путь предоставил», затем в «клиенту положено» и «приложение получило». На каждом переходе добавляется утверждение, которого исходная запись не измеряла.

Что именно считает IP-слой

IP-биты — восемь, умноженное на число октетов от первого октета IP-заголовка до конца полезной нагрузки в пакетах, правильно принятых D между T и T+I. Начало и интервал входят в идентичность результата.

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

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

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

Type P возвращает в отчёт сетевую политику

Пакеты между одними концами могут обслуживаться по-разному. Маркировка выбирает очередь, ACL отбрасывает протокол, политика меняет маршрут, балансировка отправляет поток на другие звенья. Type P описывает измеряемый поток или агрегат.

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

Конкурирующая нагрузка тоже часть контекста. Тест в момент пустой приоритетной очереди не выявляет вечное свойство. Изменение смеси, политики или маршрута меняет оперативный объект при прежней номинальной скорости.

Размер пакета меняет нижнеуровневые накладные расходы. Сжатие заголовков может передать меньше физических битов, хотя RFC 5136 считает развёрнутую IP-длину. Сравнение слоёв требует явного преобразования.

Ёмкость, использование и доступность

C(L,T,I) — максимальная скорость Type-P IP-битов, отправленных S и корректно принятых D через L в интервале. Ёмкость пути равна минимуму по звеньям. Звено этого минимума называют narrow link.

Used(L,T,I) — реально принятый IP-трафик от любых источников, не максимум. Утилизация равна Used/C. Процент без определения знаменателя, слоя и окна неполон.

Доступная ёмкость звена равна C*(1-Util), а пути — минимуму доступных ёмкостей. Соответствующее звено — tight link. Медленное, но свободное звено может иметь больший остаток, чем быстрое и загруженное; narrow и tight тогда расходятся.

Это меняет капитальное решение. Ускорение narrow link поднимает потолок, но может не разгрузить tight link. Перенос трафика улучшает запас без замены физического порта. Одинаковая фраза «добавили полосу» скрывает разные механизмы.

Время — часть доказательства

Доступность меняется вместе с использованием. RFC 5136 требует T и I и рекомендует ряд измерений. Одиночное наблюдение не бесполезно, а ограничено. Его границы нельзя удалять.

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

Свежесть — отдельное решение. Вчерашнее измерение может отлично доказывать вчерашнее состояние. После изменения очереди, маршрута, смеси или ПО оно не автоматически доказывает настоящее. Метка «последнее» не задаёт срок годности.

Две копии — двойная работа, но не двойная ценность

Если оборудование дублирует пакет и обе копии корректно получены, общее определение может считать обе. Для сырого расхода это верно. Для уникальной информации вторая копия ничего не добавляет. Условие Type P или отдельная метрика должны зафиксировать уникальность.

Более высокая скорость поэтому может означать потери эффективности. Совместное хранение сырой работы и уникальной доставки выявляет дублирование. Один итоговый объём превращает дефект в видимую производительность.

Bulk Transfer Capacity из RFC 3148 работает на транспортном слое. Она считает уникальные данные одного соединения с контролем перегрузки, исключает заголовки и повторно переданное из полезного объёма. На результат влияют потери, задержка, перестановка и алгоритм восстановления. Это не величины RFC 5136.

RFC 9097 позже уточняет методы односторонней IP-ёмкости, RFC 9946 — управляемый UDP-тест. Они улучшают воспроизводимость, но не создают бронирование, право абонента, решение SLA или успех приложения.

Минимальная цепочка квитанций

Сначала фиксируются среда, режим, согласование и NomCap(L). Затем источник, назначение, полный путь и звенья. После — слой, Type P, размеры, маркировка, правила правильного приёма, ошибок, фрагментов и дубликатов. Наконец, T, I, часы и план выборки.

Только тогда интерпретируются C по звеньям, минимум пути, использование, знаменатель утилизации, остаток и tight link. Маршрутизация, очереди и балансировка связываются с результатом. Активный тест хранит предложенную нагрузку и пределы безопасности.

Договор создаёт отдельную квитанцию: гарантированная ставка, burst, перцентиль, исключения и полномочие решения. Приложение даёт уникальные байты, целостность, повторы, время завершения и эффект. RFC 5136 не заполняет их выводом.

Расхождение слоёв полезно. Физика здорова, но Type P ограничен. IP-ёмкость высока, запас низок. Запас есть, транспорт не использует его. Передача завершилась слишком поздно. Один зелёный показатель не судит всю цепь.

Тонкая координация, полное местное доказательство

RFC 5136 даёт общий словарь и не приписывает ему лишнюю власть. Он не устанавливает и не резервирует ресурс, не выбирает путь, не разрешает тестовую нагрузку и не толкует договор.

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

Руководство не должно позволять владельцу одного счётчика оценивать весь сервис. Инвентарь отвечает за номинальную возможность, инженерия — за квалифицированное IP-наблюдение, эксплуатация — за свежесть, коммерческая власть — за обязательство, приложение — за исход.

Число на порту может оставаться истинным. RFC 5136 лишь не разрешает ему говорить от имени слоёв, которых оно не наблюдало.

Источники

  1. RFC 5136, HTML
  2. RFC 5136, текст
  3. Запись RFC Editor
  4. Запись IETF Datatracker
  5. История документа
  6. Поиск исправлений
  7. RFC 1812
  8. RFC 2330
  9. RFC 2544
  10. RFC 3148
  11. RFC 4656
  12. RFC 6349
  13. RFC 6703
  14. RFC 7312
  15. RFC 8337
  16. RFC 9097
  17. RFC 9473
  18. RFC 9946
  19. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  20. On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
  21. Running-Code Primary