Кратко
- RFC 3517 сводил накопительные ACK и блоки SACK в таблицу отправителя, после чего
SetPipe()оценивала число октетов, которые следовало считать находящимися в пути. - Некоторые повторные передачи учитывались дважды, потому что отправитель не знал, какая копия покинула сеть. Разность
cwnd - pipeразрешала отправку, но не подтверждала точный состав пути или доставку.
После нескольких потерь накопительный ACK показывает лишь непрерывную левую границу. Выше неё у получателя могут лежать отдельные острова данных. RFC 2018 позволил сообщать их блоками SACK и сократить ненужные повторные передачи.
Однако SACK оставался рекомендательной информацией. Получатель мог отказаться от уже отмеченных данных, поэтому отправитель не освобождал буфер до продвижения накопительного ACK. Сообщение описывало временное состояние, а не необратимое хранение.
RFC 3517 построил из этих свидетельств локальную модель восстановления. HighACK, HighData, HighRxt и RecoveryPoint задавали границы. Update() обновляла таблицу. IsLost() объявляла диапазон потерянным после порога более высоких разрозненных блоков или байтов. Это был вывод, а не наблюдение места потери.
SetPipe() проходила пространство последовательности. Не отмеченные SACK и ещё не признанные потерянными октеты увеличивали pipe, поскольку считались остающимися в сети. Повторно переданные данные до HighRxt тоже учитывались. Документ прямо называл результат оценкой.
Двойной учёт раскрывал предел знания. Если повторная передача происходила до признания оригинала потерянным, отправитель не знал, осталась ли одна копия или обе. Считать обе исчезнувшими означало рисковать занижением pipe и лишним трафиком. Консервативная модель сохраняла неопределённость.
При входе в восстановление RecoveryPoint становилась равной HighData, окно уменьшалось, первый предполагаемый пропуск передавался снова и запускалась SetPipe(). Каждый следующий ACK менял таблицу. Только свободный SMSS в cwnd - pipe позволял NextSeg() выбрать следующий диапазон.
Это было локальное разрешение, а не показание датчика. Увеличение pipe после передачи не доказывало очередь, пребывание на пути, приём или использование приложением. Накопительный ACK за RecoveryPoint завершал лишь один этап.
RFC 3042 применял первые дубликаты ACK в Limited Transmit. RFC 2883 добавил D-SACK для дубликатов. RFC 5681 задавал рамки управления перегрузкой, а RFC 6582 описывал NewReno. Все они улучшали решения без физического подсчёта сети.
RTO оставался запасной границей. После тайм-аута прежний SACK нельзя было считать постоянным из-за reneging. Даже подробная таблица имела срок и предпосылки.
RFC 6675 заменил RFC 3517, уточнил пороги и спасательные передачи, но сохранил pipe как оценку. RFC 6937 позднее предложил PRR и иной ритм восстановления. История показывает, что такая бухгалтерия является политикой управления.
Основой TCP теперь служит RFC 9293, а IANA регистрирует SACK-Permitted и SACK. Регистрация подтверждает полномочие кода, а не применение, потерю или доставку. Наследие RFC 3517 состоит в способности действовать по неполным данным, не выдавая их за полную реальность.
Источники
- https://www.rfc-editor.org/rfc/rfc3517.html
- https://www.rfc-editor.org/rfc/rfc3517.txt
- https://www.rfc-editor.org/info/rfc3517
- https://datatracker.ietf.org/doc/rfc3517/
- https://datatracker.ietf.org/doc/rfc3517/history/
- https://www.rfc-editor.org/errata_search.php?rfc=3517
- https://www.rfc-editor.org/rfc/rfc2018.html
- https://www.rfc-editor.org/rfc/rfc2883.html
- https://www.rfc-editor.org/rfc/rfc3042.html
- https://www.rfc-editor.org/rfc/rfc5681.html
- https://www.rfc-editor.org/rfc/rfc6582.html
- https://www.rfc-editor.org/rfc/rfc6675.html
- https://www.rfc-editor.org/rfc/rfc6937.html
- https://www.rfc-editor.org/rfc/rfc9293.html
- https://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров
