>If we just accept "networks are unreliable and sometimes broken" as a fact of life, things will never get better. I applaud the unsung heroes who are finding and fixing the actual root causes of lower layers of our networks.
As developers, this should always be a fact of life. True, we should strive for making the networks perfect, but at the end of the day, these things still need to be accounted for.
Because you don't have control over a client deciding that 50 cent network cards are "good enough" for their deployment even though they've demanded five 9's uptime from your software.
Because you can't know when someone's going to spill beer on the switch.
Because someone's just going to pull the wrong cable.
Because the water company accidentally cut the line into the building.
You're mostly talking about reliability at the physical layer, which as you say is never going to be perfect. Csense is talking about reliability at the link layer and above, which is infinitely more attainable.
If you can't guarantee that every layer below you is absolutely reliable, then you need to assume that everything below you might be broken, and that you need to handle it. You can't start with the mindset that everything works below you, and have everything above you also work fine.
The fact that we have people with the mindset that everything below them is broken is the entire reason that these kinds of issues get detected and fixed.
Yeah if you try and work around broken PMTUD though you're going to mess up your application layer protocol SO bad...
EDIT: I suppose you could rewrite TCP MSS on your own firewall or drop MTU on all web servers.... but of course if you're going to reconfigure your firewall / intefaces, you may as well just fix the problem - which was caused by poor device configuration in the first place.
You also can't know when someone between you and the other endpoint has configured something stupidly. :)
As a sysadmin, I do my best to make the network as damn near perfect as possible; but as a developer, I still generally assume the network is unreliable and plan accordingly.
As developers, this should always be a fact of life. True, we should strive for making the networks perfect, but at the end of the day, these things still need to be accounted for.
Because you don't have control over a client deciding that 50 cent network cards are "good enough" for their deployment even though they've demanded five 9's uptime from your software.
Because you can't know when someone's going to spill beer on the switch.
Because someone's just going to pull the wrong cable.
Because the water company accidentally cut the line into the building.