5. Обработка сообщений в старом стиле на хосте
В этом разделе мы выделим несколько возможных стратегий для хоста, получающего сообщение «датаграмма слишком большая» от не модифицированного маршрутизатора (т.е. с нулевым полем Next-Hop MTU). Этот раздел не является частью описание протокола.
Самая простая вещь, которую может сделать хост в ответ на такое сообщение это прекратить установку бита DF и принять, что это PMTU равно текущему PMTU или 576, в зависимости от того, что меньше. Таким образом, хост возвращается к тому же самому PMTU, как это делается в текущей практике (см. раздел 3.3.3. RFC 1122 «Рекомендации для хостов Internet — коммуникационные уровни»). Эта стратегия имеет преимущество, так как она отрабатывает быстро, что делает ее не хуже, чем там та, что используется в существующей практике. Она не работает, однако, для предотвращения фрагментации в некоторых случаях, и дает наиболее эффективное использование утилизации в других случаях.
Более сложные стратегии «ищут» точную оценку PMTU, посылая пакеты разного размера с установленным битом DF. Хорошей поисковой стратегией можно назвать ту стратегию, которая получает точную оценку PMTU при малом количестве потерянных пакетов в процессе поиска.
Некоторые стратегии применяют алгоритмические функции к предыдущей оценке PMTU для того чтобы получить следующую оценку PMTU. Например, старая оценка PMTU может быть умножена на константу (скажем, 0.75). Мы НЕ рекомендуем их; они сходятся слишком долго и могут недооценить правильное значение PMTU.
Более сложный подход делать бинарный поиск по размеру пакета. Он сходится несколько быстрее, хотя все еще требуется 4-5 шагов для того чтобы перейти от FDDI MTU к Ethernet MTU. Серьезный недостаток состоит в том, что требуется сложная реализация алгоритма индикации занижения текущей оценки PMTU. Мы так же не рекомендуем пользоваться этой стратегией.
Появилась одна стратегия, которая работает, кажется, весьма хорошо. Она стартует с обзора значений, которые практически в относительно небольшом количестве используются в Internet. Таким образом, вместо того, чтобы слепую проводить поиск среди произвольно выбранных значений, мы можем искать только среди тех, которые действительно могут использоваться. Более того, так как у разработчиков прослеживается тенденция выбирать MTU подобными путями, возможно накопление групп похожих значений MTU и использовать наименьшее значение в группе как наше поисковое «плато». (Понятно, что лучше недооценить значение MTU на несколько процентов, чем переоценить его на один октет).
В разделе 7, мы описываем, как мы пришли к таблице репрезентативных плато MTU (representative MTU plateaus) для использования при оценке MTU. Сходимость с этой таблицей такая же хорошая, как бинарный поиск в самом худшем случае и намного лучше в обычном случае (например, требуется только два шага для перехода от FDDI MTU к Ethernet MTU).
Любая поисковая стратегия должна иметь некоторую «память» о предыдущих оценках, чтобы делать следующие. Один подход должен использовать оценки PMTU, кэшированные в настоящее время, но фактически лучше информация, полученная из сообщения «датаграмма слишком большая». Все ICMP сообщения «адресат недоступен» содержат, включая упомянутое, IР заголовок оригинальной датаграммы, которая была слишком велика для передачи без фрагментации. Так как поле Total Length может быть меньше, чем текущее PMTU, но, тем не менее, больше, чем фактическое PMTU, то это может послужить входными данными методу, производящему следующую оценку PMTU.
Замечание: маршрутизаторы, основанные на 4.2BSD Unix, посылают неправильное значения поля Total Length оригинальной датаграммы. Значение, посылаемое этими маршрутизаторами, является суммой оригинального поля Total Length и Header Length (выраженное в октетах). Так как хост может получить такое сообщение «датаграмма слишком большая», зная, что датаграмма была получена от одного из таких маршрутизаторов, хост должен быть консервативен. Если возвращенное поле Total Length не меньше, чем текущая оценка PMTU, то оно должно быть уменьшено до четверти значения поля Header Length.
Стратегию, которую мы рекомендуем, состоит в том, чтобы использовать следующую оценку PMTU как наибольшее основное значение, которое меньше, чем то, что возвращается в поле Total Length (исправленное, если необходимо, в соответствии с замечанием выше).