6.4. Действия уровня ТСP
Уровень ТСР должен отслеживать значение PMTU для адресата, он не должен посылать датаграммы размером больше PMTU. Простая реализация может узнавать это значение у уровня IP (используя интерфейс GET_MAXSIZES описанный в RFC 1122) каждый раз, когда создает сегмент, но это было бы не эффективно. Кроме того, реализации ТСР, которые используют алгоритм медленного старта [4] обычно вычисляют и кэшируют несколько значений, полученных из PMTU.Может быть проще получить асинхронное уведомление, полученное при изменении PMTU, так, чтобы эти переменные могли быть модифицированы.
Реализации ТСР должны так же сохранять значение MSS (которое по умолчанию равно 536), и не посылать сегменты больше этого MSS, не зависимо от PMTU.
В реализациях, основанных на BSD 4.x это требует добавления дополнительного поля в запись состояния ТСР.
Наконец, когда получено сообщение «датаграмма слишком большая», подразумевается, что датаграмма была отброшена маршрутизатором, который послал это сообщение. Достаточно обработать это как любой другой отброшенный сегмент и ждать, пока таймер повторной передачи не истечет, чтобы вызвать повторную передачу сегмента. Если процесс определения PMTU требует несколько шагов для правильной оценки PMTU, это может задержать соединение во много раз.
С другой стороны, повторная передача могла быть сделана в непосредственном ответе на уведомление о том, что значение PMTU было изменено, но только для определенного подключения, указанного в сообщении «датаграмма слишком большая». Размер датаграммы используемый при повторной передаче должен быть, конечно, не больше чем новый PMTU.
Замечание: НЕЛЬЗЯ повторно передать в ответ на каждое сообщения «датаграмма слишком большая», так как выброс сегментов с завышенными размерами приведет к нескольким повторным передачам тех же самых данных. Если новая оценка PMTU все еще не верна, процесс повторится, что приведет к экспоненциальному росту числа отправленных лишних сегментов.
Это означает, что уровень ТСР должен быть способен распознать, когда сообщение «датаграмма слишком большая» действительно уменьшает PMTU, который уже был использован для отправки датаграмм на данном соединении и что нужно игнорировать другие уведомления.
Современные реализации ТСР используют алгоритмы «медленного старта» и «предотвращения скоплений» («congestion avoidance») для увеличения эффективности работы. [4]. В отличие от повторной передачи, вызванной истечением таймером повторной передачи, повторная передача, вызванная сообщением «датаграмма слишком большая» не должна менять окно накопления (congestion window). Это должно, однако, вызывать срабатывание механизма медленного старта (т.е. только один сегмент должен быть повторно передан, пока не подтверждения не начнут поступать снова).
Эффективность работы ТСР может быть уменьшена, если максимальное окно отправителя не кратно используемому размеру сегмента (это не размер окна накопления, который всегда является кратным размеру сегмента). Во многих системах, (например, основанных на BSD 4.2) размер сегмента обычно кратен 1024 октетам, так что надлежащие отношения ставятся по умолчанию. Если используется определение PMTU, то конечно размер сегмента может не быть кратен посылаемому пространству (may not be a submultiple of the send space) и он может изменяться в период существования соединения; это означает, что уровень ТСР может быть нуждается в изменении размера передающего окна, когда PMTU меняет свое значение. Максимальный размер окна должен быть установлен равным наибольшему кратному размеру сегмента (PMTU - 40), что должно быть меньше или равно размеру буфера пространства отправителя (sender's buffer space size).
Процесс определения PMTU не должен воздействовать на значение, отправляемое у опции MSS, потому что это значение используется на другом конце соединения, которое может использовать несвязанное значение PMTU.