>> 4) We toss caution to the wind and let modern routers deal with UDP >> frags ....
> This is a horrible idea. Fragmentation of a large IP datagram increases > both the likelyhood that it will be lost and the amount of data that must > be retransmitted if it is, as opposed to use of a PMTU-sized datagram. > This means that if the network is congested, packet loss will lead to more > retransmits and more packet loss, making the problem worse. It is > essential that any protocol carrying a signficant amount of traffic > discover and follow the path MTU. Discovering the local interface MTU is a > critical part of this process, since sending a larger-than-MTU packet will > result in local fragmentation, which has all the problems I just described > and prevents discovery of the true path MTU. Correct me, but doesn't RX emmit MTU*RX_MAX_FRAGS sized packets instead of packets that in their entire size fit into one UDP packet? Unfortunately, misconfigured firewalls will prevent path MTU discovery on the Internet in the future, so I have given up on any chance of bigger than Ethernet-sized packets on WAN connections. And what is WAN and what not must be configured by hand. Don't get me started ;-) So if RX really is not caring about the MTU so much, why not say 1400 for the moment and get it over with? And Dale, if you are still listening after my rant about MTU sizes, there ARE folks that really want to roll out that Solaris patch... Thanks for listening, Harald. _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
