[ On Thursday, November 18, 1999 at 22:03:21 (-0500), Randy Bush wrote: ]
Subject: Re: should TCPs do MTU black hole detection?
>> o when it breaks, the noc gets the call, debugs it, and it gets fixed
> ^^^^^^^^^^^^^
> Optimist!
but at least the user knows where the problem lies, as opposed to
I certainly agree with you here Randy!
However as a reasonably expert user there are times when I want the
ability to have my equipment try to work around even ultra-stupid
configurations elsewhere on the net, especially when those of us
experiencing the problem are far more rare than those who do not.
Some time ago when I first began to personally experience this problem
with path MTU discovery on my home network I discovered through analysis
of the upstream packet traces that it was almost always possible to have
the router sending the needs-frag reply to realize when its attempts to
do so were futile and thus enforce fragmentation anyway. While this may
make some protocols un-usable anyway it could at least allow me to limp
along and to allow me to use that same network to communicate with the
offending people at the other end using protocols affected by this
problem such as SMTP, FTP, HTTP, etc.
Unfortunately I have not yet had time (or in this case the need -- I've
since increased my link's MTU to 1500 :-), to implement this algorithm
in my own upstream router (which thankfully I do have the root password
for! ;-).
BTW, I think my algorithm provides a much more efficient work-around to
the problem than black-hole discovery. Unfortunately it also makes it
harder to convince the offending admins to fix their stupid filter
definitions (or alternately at least turn off PMTUd in their servers).
What I'd really like to do is find some way to enhance my algorithm in
such a way that it could send a tiny tactical nuke down the wire after
my connection to/through the offending network safely closes. I.e. I
want to cause grief to any ICMP filter that has caused my router to have
to work around its stupidity! 