注重：这种通知机制与ICMP源路由抑止提供的通知机制是类似的 。在一些实现中（诸如源自4.2BSD的系统），现在存在的通知机制不能识别非凡的相关连接，所以，一个附加的机制是必要的 。
作为选择，一种实现能够避免使用对于PMTU减小的异步通知机制，这种机制是通过延迟通知直到下一次尝试发送一个比PMTU估计值大的数据报 。在这种方法中，当尝试发送一个带有DF比特位设置的数据报，并且这个数据报比PMTU估计值大，SEND函数会失败，返回一个适当的错误指示 。这种方法可能更适合于非连接的打包层（例如使用UDP的打包层），它（在一些实现中）可能很难从ICMP层通报 。在这种情况下，正常的基于超时的重传输机制被使用于从丢失的数据报中恢复 。
应该知道打包层实例使用的PMTU改变路径的通知与包被丢弃的非凡通知有区别，了解这一点很重要 。后者是比较实用的（即，从打包层实例的观点来看是异步的），而前者可能有延迟直到打包层实例想创建一个包 。仅当已知包丢失，才应该重传，这由数据报太大报文指定 。
6.3清除过时的PMTU信息
互联网网络拓扑结构是动态变化的；路由随着时间改变 。假如新的路由开始被使用，对指定目的地已发现的PMTU可能是错误的 。因此，在主机中缓存的PMTU信息可能变得过时 。
因为使用PMTU发现的主机总是设置DF比特位，假如过时的PMTU值太大，一旦一个数据报被发送给指定的目的地，就会立即发现这种情况 。认为过时的值太小的机制不存在，所以一个实现应该使缓冲值“变老” 。当一个PMTU值一段时间内没有减少（在预订的10分钟内），PMTU估计值应该被设置为第一跳数据链路MTU，打包层应该被通知这种改变 。这将导致完全的PMTU发现过程再次发生 。
注重：实现应该提供改变超时持续时间的方法，包括设置它为“无限” 。例如，连接在FDDI网络上的主机通过一条低速的串行线接入因特网将不会发现一个新的非本地的PMTU，所以它们不必忍受每十分钟丢弃数据报 。
在响应PMTU估计值增长的时候，上层不必重传数据报 。因为在响应丢弃数据报的指示的时候，增长从不发生 。
一种实现PMTU老化的方法是在路由表条目中加入时间戳字段 。这个字段初始化为一个“保留”值，表明PMTU从没改变过 。当响应一个数据报太大报文，PMTU减少的时候，时间戳被设置为当前时间 。
通过时间驱动的过程将立即处理路由表，对于时间戳不是“保留”并且比超时时间间隔老的条目：
－PMTU估计值被设置为第一跳的MTU 。
－使用路由的打包层被通知这种增长 。
假如主机路由被删除，PMTU估计值可能从路由表中消失；这可能发生在响应一个ICMP重定向报文的情况中，或者因为某些路由表守护程序在几分钟后删除了旧的路由 。在一个多宿主主机上拓扑改变也可能导致使用不同的源接口 。当这种情况发生，假如打包层没有被通知，那么它可能继续使用对现在来说太小的缓冲PMTU值 。一种解决方法就是当重定向报文导致路由改变和路由从路由表中删除时通知打包层PMTU可能改变 。
注重：检测PMTU增长的更高级复杂的方法在7.1节中描述 。
6.4TCP层的行为
TCP层必须追踪连接到目的地的PMTU；不应该发送比它还大的数据报 。一个简单的实现可能在每次创建一个新的段的时候，向IP层请求这个值（使用在[1]中描述的GET_MAXSIZES接口），但是这种方法效率不高 。而且遵守“慢启动”避免阻塞算法[4]的TCP实现计算和缓存从PMTU得到的一些其它的值 。当PMTU改变的时候接收异步的通知较为简单，以至于这些变量可以更新 。
推荐阅读
- 最大分段 小议TCP的MSS以及MTU
- Z710c的r1jc002版本软件的新发现
- vivox23幻彩版怎么去掉照片水印
- P768暂时发现的不足和我的感觉
- 关注P768真机以来，发现的几个缺点！
- 联想z6怎么修改照片存储路径
- TCP的路径MTU发现问题
- 美颜相机中打马赛克具体操作流程
- 关于p768的功能和待机时间
- 世界上最长的蚯蚓是在哪里发现的