North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: PMTU-D: remember, your load balancer is broken
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 Attachment:
pgp00001.pgp
|