On Tue, 13 Jun 2000 22:36:08 MDT, Marc Slemko said:
I shouldn't get started here. I have trouble buying into HP's way of doing things (I was only aware that HPUX did this; but it seems that AIX does too...). If you run a high traffic DNS server
AIX started supporting PMTU-D for both TCP and UDP in 4.2.1. The gotcha was it being on by default in 4.3.3.
on an AIX box without disabling this "feature" then you must just be spewing ICMP echo requests. It could add up to more bytes than your DNS responses...
Well, as I said, it was done in error, and yes, the bytes for the ICMP *were* running almost as high as the actual NTP traffic... The surprising part is that it was broken for close to 3 months before somebody noticed (yesterday, just a few hours before this discussion started, in fact). As noted, PMTU-D for TCP is a lot lighter weight, and has an actual chance of winning sometimes. Does anybody know of a UDP-based application that is able to *do* anything with PMTU-D? A co-worker had heard of research at PSC that dealt with TCP-friendly multicast, but that was all we could think of...
And, obviously, ICMP pings don't work too well much of the time anyway. And I'm concerned about the possibility of some nasty DoS potential by exploiting this. I haven't looked into this in depth, and it depends on how it handles cache replacement, etc.
Except that, technically, you are not permitted to just blindly send segments of such size. Well, you can but systems in the middle don't have to handle them. No?
Hmm.. either I did a bad job of explaining or I haven't had enough caffiene to parse what you said. Given that you also suggest going to a 1460 MSS, I suspect that we're actually violently in agreement here. Now if I can remember why I chose 1396 for a default MSS.... ;)
It is also a concern that, in my experience, many of the links with MTUs <1500 are also the links with greater packet loss, etc. so you really don't want fragmentation on them.
The worst part here is that I suspect that most of these links (just on sheer numbers of shipped product) are the aformentioned Win98 576-MTU. However, in this case, the fragmentation happens in a terminal server on the last hop, and hopefully the case of a terminal server running out of queueing buffers and having to drop one of the 2 remaining fragments of a 1500->576 split after sending the first one is pretty rare.... I seem to remember that the *original* motivation for slow-start and all that was Van Jacobson's observation that the most common cause of a TCP retransmit was that an *entire* packet had been silently dropped due to queueing congestion, and could thus be treated identical to an ICMP Source Quench. Has this changed? Has "fragmentation" become a Great Evil, rather than an annoyance that some links have to deal with?
I think it is simply that we the net is in a state of somewhat amazing homogoney right now. I don't think this will continue, but who knows. I do think that PMTU-D is an important feature, and people should be encouraged to leave it enabled wherever possible, so that one day if networks do change to make it more useful in the general case, it will be there...
At least for TCP. I'm still unconvinced for UDP ;) -- Valdis Kletnieks Operating Systems Analyst Virginia Tech