On Mon, 10 May 2004, Masataka Ohta wrote: > Dean Anderson; > > >>I recommend that, to avoid long initial delay and intermediate > >>lack of communication after path changes of, PMTUD should turnd > >>off by default and should be activated only on extreme > >>conditions. > > > Just the opposite, unless you want to lose connectivity with a number of > > web servers that want to send big packets with DF turned on. > > There were (still are?) number of web servers that wanted to send > big packets with DF turned on, because PMTUD was turned on on the > servers but ICMP errors were filtered. There still are such apps. I ran into this recently, last winter. I'd suggest those complaining should get a few more clues about what ICMP does, and stop filtering ICMP packets that aren't threatening. The network can't possibly work if people are going to turn critical parts of it off, parts that they don't fully understand. There is no surprise that they have problems. This isn't a reason to change the network. There are other things that they don't understand, and could turn off. One can't remove all switches and levers. > > A number of commercial > > products and applications do rely on PMTU to work, and will do an PATH MTU > > discovery, and send the MTU sized packets with DF (don't frag). > > and send packets larger than MTU expecting to receive ICMP > errors in vain. > > Read the original mail of the thread on the reality. I think we disagree on the "reality". The reality is that most sensible people and ISPs don't block harmless ICMP messages. Of course, not _all_ ICMP messages from anywhere are harmless, but that doesn't mean that all such messages are all harmful. Blocking everything is a club-footed method of security, if you'll pardon the pun. Those that pick such an approach cannot be accomodated, because they're clubfooted, as it were---if it isn't this, its something else. Cluelessly turning things off will have a bad effect on any system. Case in point: It seems that something similar (in principle anyway) was what caused the Three Mile Island Nuclear Plant to melt down: The operators turned off the emergency cooling system pumps wrongly. It took an engineer to tell them to turn them back on, but by then it was too late to prevent damage. People have suggested that the switch to turn off the pumps should be removed from all nuclear plants. This is also wrong. There might be a need to do that someday. The solution is to better train the operators, so that they don't mess with things they don't fully understand. This is just as true of networks, as it is of nuclear power plants. Probably more so of networks, since these sorts of things happen more frequently, and even the network engineers aren't nearly as uniformly trained, much less so the operators. > > This is the first I have heard that path mtu discovery software was > > unreliable. > > PMTUD software is unreliable!? > > Then, it is anther reason to avoid it. > > Can you tell me who said it with an appropriate reference? Err, _you_ said it: On Sat, 8 May 2004, Masataka Ohta wrote: > Further, it should be noted that PMTUD is so unreliable that > no applications rely on it, which means that even under > extreme conditions rational operators won't turn on PMTUD. > > In short, forget PMTUD. > Masataka Ohta > > _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf