I expected that most hosts would send packets with DF=1, using RFC 1191 PMTUD, since it has been around since 1990 . . . and that it would be considered antisocial to send any longish packets into the Net with DF=0, saying the Network should do extra work if the packets are too long for it.
In fact, some servers - including at least some Google servers, send only DF=0 packets, and therefore never do any PMTUD. They won't be tempted by the client having a higher MSS than their own 1430, but as long as the client's MSS is this or above, the server frequently sends 1470 byte packets with DF=0. http://www.firstpr.com.au/ip/ivip/ipv4-bits/actual-packets.html#google-no-pmtud I find this interesting: 1 - I guess Google figure 1470 is a packet size which generally works in the core. 2 - I guess they figure that if the client advertises an MSS and when 40 (IP and TCP headers) is added to that figure if the result is larger than any MTU limit between the client and Google's servers, then it is the client's problem. If lots of hosts are sending long packets with DF=0, we need to cope with then in any map-encap scheme. We don't want to have to fragment these packets before encapsulation, or after, but we have no way of telling the host to send smaller ones. Another perplexing discovery is that my web server in Texas does ordinary TCP SYN handshakes with MSS values such as 1460 from both sides and then quite merrily cranks up to packets of 7260 bytes and longer. http://www.firstpr.com.au/ip/ivip/ipv4-bits/actual-packets.html#jumbo1 I have no idea why this occurs, but at least it does it all with DF=1. These packets are received and acknowledged by clients who are presumably on some kind of xDSL service. So jumboframes are alive and well in the core. - Robin -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
