Кратко

  • RFC 3133 определял доли доставки полезных октетов и кадров для одного направления одного виртуального соединения Frame Relay, отдельно для гарантированной и избыточной нагрузки.
  • Документ предупреждал: потеря маленького подтверждения может вызвать повторную передачу множества данных. Число остаётся верным в своих границах, но не доказывает хороший результат приложения.

Один короткий кадр менял судьбу длинной передачи

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

RFC 3133 привёл этот механизм в обсуждении Data Delivery Ratio и Frame Delivery Ratio. Отброшенный небольшой кадр с подтверждением мог привести к повторной передаче большого количества кадров данных. Сеть сообщала хорошую долю доставки, а пользователь наблюдал низкую производительность.

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

Физическая скорость не равнялась обещанию

В Frame Relay существовало несколько величин, которые легко смешать под словом «пропускная способность». Access Channel был физическим пользовательским каналом, а Access Rate задавал максимальную скорость ввода данных. Но договор мог гарантировать меньшую часть этой скорости.

Committed Information Rate, CIR, обозначал скорость, которую сеть поддерживала между точками услуги при наличии данных. Bc задавал объём битов, согласованный для нормальной передачи в интервале Tc. Be описывал дополнительный негарантированный всплеск, который сеть могла попытаться доставить с меньшей вероятностью.

Tc не был периодическим временным окном. RFC описывал его как скользящий интервал, запускаемый поступлением данных и вычисляемый как Bc/CIR. Чтобы отличить гарантированную нагрузку от избыточной, требовались параметры договора и временная последовательность, а не только скорость порта.

Бит Discard Eligible, DE, задавал предпочтение при отбрасывании во время перегрузки. Он не доказывал, что кадр действительно отбросили. RFC 3133 развёл discardable и discarded. Помеченный кадр мог пройти, если перегрузка исчезла. Непомеченный мог стать кандидатом по политике PVC, IP-адреса или порта. Ошибочный кадр могли удалить ради целостности.

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

У процента было направление и место жительства

RFC 3133 использовал формат определений RFC 1242 и различал документы терминологии и методологии. Первые называли измеряемую величину, вторые задавали процедуру. Формула сама по себе не означала проведённого испытания.

DDR сравнивал успешно доставленные октеты полезной нагрузки с предложенными октетами; поле адреса и FCS не входили в payload. Frame Delivery Ratio сравнивал успешные приёмы кадров с попытками передачи. Обе метрики относились к одному направлению единственного виртуального соединения.

Поэтому полнодуплексная связь имела два независимых набора значений. Хороший прямой путь данных не доказывал исправность обратного пути подтверждений. Результат одного DLCI не описывал все цепи порта. Измерение между двумя точками не включало автоматически события до входа и после выхода.

Общую долю можно было разделить. DDR_c относился к нагрузке внутри CIR, DDR_e — к превышению; кадры делились аналогично. Арифметически правильный итог мог скрыть, что гарантированная часть работает хуже негарантированной.

Перед интерпретацией следовало назвать виртуальное соединение, направление, интервал, класс нагрузки, определение payload и точки наблюдения. Без этих координат десятичная точность не давала числу проверяемой юрисдикции.

Функциональный вес не измеряется длиной

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

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

Можно придумать пример, где дошли 999 кадров из тысячи, и получить 99,9 процента. Но RFC 3133 не публиковал такой опыт. В нём нет названного устройства, приложения или измеренного коэффициента усиления. Подтверждена более узкая возможность: потеря маленького подтверждения может вызвать множество повторных кадров данных.

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

Средняя задержка видела только прибывших

Frame Transfer Delay измерял время от события выхода кадра из одной точки до входа в другую. Среднее вычислялось по полученным кадрам. Кадры, отправленные во время интервала, но не доставленные, в расчёт не входили.

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

Frame Transfer Delay Variation был разностью максимальной и минимальной наблюдаемой задержки. RFC связывал сильную вариацию с вычислением RTT и throughput TCP, а избыточную задержку — с ущербом для приложений вроде передачи голоса по IP. Это технические зависимости, не результаты именованной сети.

Иногда отбрасывание защищало результат

Документ перечислял ошибочные кадры: слишком длинные или короткие, с неверным числом битов, неизвестным DLCI, abort sequence, неправильными флагами или проваленным FCS. Отбросить повреждённый кадр могло быть лучше, чем переслать его, потому что повторная передача приносила чистую копию.

Один discard counter мог объединить контрактный policing, приоритет при перегрузке и проверку целостности. Все три могли вызвать восстановление выше, но у них разные причины, владельцы и способы исправления.

Расследованию требовалось происхождение события. Увидели ли кадр на входе? Был ли он committed или excess? Имел ли DE? Какая политика его выбрала? Почему его действительно отбросили? Где исчезло обратное подтверждение? Что повторил транспорт? Завершило ли приложение операцию? Итоговый процент не содержал этих ответов.

Терминология, а не рейтинг оборудования

RFC 3133 был опубликован в июне 2001 года как Informational-документ группы IETF Benchmarking Methodology. Он расширял RFC 1242, RFC 1944 и RFC 2285, используя также понятия Frame Relay Forum и MIB услуги Frame Relay.

Он не испытывал конкретное устройство, не сертифицировал оператора и не доказывал наличие всех счётчиков, выполнение SLA, распространённость или удовлетворённость пользователей. Последний Internet-Draft показывает редакционную историю текста, не внедрение.

RFC 1944, RFC 2544 и RFC 2889 описывали соседнюю методологию. RFC 2761 давал контекст ATM, RFC 2954 — managed objects, а более поздний RFC 6349 — framework для тестов throughput TCP. Ни один из них не превращает определения RFC 3133 в полевой результат.

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

Три журнала вместо одного зелёного индикатора

Сетевой журнал должен хранить Access Channel, DLCI, направление, интервал, CIR, Bc, Be и Tc; предложенные и доставленные октеты и кадры; разбивку committed/excess; DE, policing, FECN/BECN, ошибки, причины discard и границы измерения.

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

Пустые поля верхних журналов нельзя заполнять нижней долей. DDR доказывает отношение payload octets в заявленном диапазоне. Кадровая доля доказывает отношение кадров. Они не являются квитанцией завершения, исполнения договора или человеческого опыта.

Frame Relay ушёл с переднего плана, но соблазн остался. Системы выбирают самый дешёвый агрегируемый сигнал и называют его здоровьем. RFC 3133 предлагает более строгую дисциплину: сохранить число, сохранить его границы и потребовать независимое свидетельство до того, как сетевое измерение станет приговором всей услуге.

Источники

  1. https://www.rfc-editor.org/rfc/rfc3133.txt
  2. https://www.rfc-editor.org/info/rfc3133
  3. https://www.rfc-editor.org/rfc/rfc3133.html
  4. https://www.rfc-editor.org/rfc/rfc1242.html
  5. https://www.rfc-editor.org/rfc/rfc1944.html
  6. https://www.rfc-editor.org/rfc/rfc2285.html
  7. https://www.rfc-editor.org/rfc/rfc2544.html
  8. https://www.rfc-editor.org/rfc/rfc2761.html
  9. https://www.rfc-editor.org/rfc/rfc2889.html
  10. https://www.rfc-editor.org/rfc/rfc2954.html
  11. https://www.rfc-editor.org/rfc/rfc6349.html
  12. https://datatracker.ietf.org/doc/html/draft-ietf-bmwg-fr-term-06