TCP实现也必须存储从它的对等者那里接收的MSS值（默认为536），不发送任何比MSS大的段，而不管PMTU的值是多少 。在源自4.xBSD的实现中，这需要加入一个附加的字段给TCP状态记录 。
最后，当收到数据报太大报文的时候，这意味着一个数据报被发送这个ICMP报文的路由器丢弃 。把它作为任意其它种类被丢弃的段，等待重传计时器期满导致这个段重传，这样的行为就足够了 。假如PMTU发现过程需要一些步骤来估计正确的PMTU，这可能因为要往返许多次数据报而造成连接延迟 。
作为选择，重传可以在对路径MTU已改变的通知立即响应时发生，但是这仅仅对于由数据报太大报文指定的特定连接 。使用在重传中的数据报尺寸当然应该没有新的PMTU大 。
注重：在响应每一个数据报太大报文的时候一定不要重传相同大小的段，因为特大型的段的突发将造成这样的报文，所以会重传同样的数据 。假如新估计的PMTU值仍然错误，这个过程重复，送的多余段的数量将成几何级增长 。
这意味着当数据报太大通知实际上减少已经使用在给定的连接中发送数据报的PMTU时，TCP层必须能够识别，并且忽略任何其它的通知 。
现代的TCP实现把“避免阻塞”和“慢启动”算法结合起来提高性能[4] 。不象由TCP重传超时导致的重传，由数据报太大报文导致的重传不应该改变拥塞窗口 。然而，它应该触发慢启动机制（即，只有一个段将被重传直到确认开始到达） 。
假如发送者最大窗口的尺寸不是使用中段尺寸的准确的倍数（这不是拥塞窗口尺寸，它总是段尺寸的倍数），TCP性能可能降低 。在许多系统中（诸如从4.2BSD中发展的系统），段尺寸总是设置为1024字节，最大窗口尺寸（“发送空间”）总是1024字节的倍数，所以，这种适当的关系保持为默认 。然而，假如PMTU发现被使用，段尺寸可能不是发送空间的约数，而且它可能在连接中改变；这意味着当PMTU发现改变PMTU值时，TCP层可能需要改变传输窗口尺寸 。最大窗口尺寸应该被设置为小于或等于发送者缓冲区空间尺寸的段尺寸(PMTU-40)的最大倍数 。
PMTU发现不影响在TCPMSS选项中发送的值，因为这个值用在连接的另一端，它可能使用一个不相关的PMTU值 。
6.5其它传输协议的问题
一些传输层协议（例如ISOTP4[3]）在重传的时候，不答应重新打包 。也就是说，一旦试图传输某种尺寸的数据报，它的内容就不能分成较小的数据报重传 。在这种情况下，原始数据报应该不设置DF比特位重传，答应它作必要的分段来到达它的目的地 。当第一次传输的时候，后来的数据报应该没有路径MTU答应值大，并且应该设置DF比特位 。
在许多情况下，Sun网络文件系统（NFS）使用远程过程调用（RPC）协议[11]发送必须分段的数据报，甚至对第一跳链路也是如此 。在某些情况下，这可能提高性能，但是众所周知它也导致可靠性和性能的问题，尤其是当客户端和服务器被路由器分开的时候 。
当涉及到路由器的时候，我们建议NFS实现使用PMTU发现 。大多数NFS实现答应在安装的时候改变RPC数据报尺寸（间接的，通过改变有效文件系统块尺寸），但是可能需要一些修改来支持以后的改变 。
而且，因为一个单一的NFS操作不能分开成一些UDP数据报，某些操作（主要是在文件名和目录上的操作）需要可能比PMTU大的最小数据报的尺寸 。NFS实现不应该减少数据报的尺寸小于这个极限值，即使PMTU发现建议了一个较小的值 。（当然，在这种情况下数据报发送时不应该再设置DF比特位 。）
6.6治理接口
我们建议实现提供一种适合于系统公用程序的方法：
推荐阅读
- 最大分段 小议TCP的MSS以及MTU
- Z710c的r1jc002版本软件的新发现
- vivox23幻彩版怎么去掉照片水印
- P768暂时发现的不足和我的感觉
- 关注P768真机以来，发现的几个缺点！
- 联想z6怎么修改照片存储路径
- TCP的路径MTU发现问题
- 美颜相机中打马赛克具体操作流程
- 关于p768的功能和待机时间
- 世界上最长的蚯蚓是在哪里发现的