Re: TTL exceeded
So standard response :)
The internet protocol is specifically limited in scope to provide the
functions necessary to deliver a package of bits (an internet
datagram) from a source to a destination over an interconnected system
of networks. There are no mechanisms to promote data reliability,
flow control, sequencing, or other services commonly found in
And oddly, also became part of discussions around the 'Interplanetary Internet', or 'Ciscos in Spaaaace!' as I called it before being disinvited. People doing space comms had some really neat, lighweight and reliable protocols used to communicate with spacecraft, satellites and probes to deal with latency, reliability and all the things IP relies on applications or the network to figure out.
TCP is one simple example. It built on IP to add some of the stuff that was missing. So FCS via SYN/ACK, MTU sizes, checksums, etc. Send a packet, wait for the ACK, send next packet.. Which is ok when latency is low, but as it increases, delays from SYN/ACK increase, so throughput decreases. Hence why FTP'ng a file from say, London-NY via a 1Gbps link won't get you close to 1Gbps throughput given the latency. So that's the 'Long Fat Pipe' issue. Transmit it via UDP instead and you'll be able to saturate the link.. But UDP's fire and forget, so if there's any dropped packets, the app needs to know. Somehow. Especially if your file transfer isn't the only traffic on that link, then you may be wanting some kind of congestion avoidance/management.. Which IP doesn't include.
There are other workarounds, like selective ACK'ng, but caution is sometimes needed. A reason why the Internet went global is it's 'open standards', which is great when they're really open and compatible with other vendor's implementations.
There can be other challenges, like a 'simple' MTU size & dealing with fragmentation, especially between layers. So common issue can be fragmentation on '1500' byte packets over Ethernet (especially emulated Ethernet) that has <1500byte payload frame. Which can be an issue on xDSL links given the way they're delivered. In the good'ol days, that could also be an issue for folks with 3Com networks because that used a larger MTU size. Stock answer to new customers saying they couldn't get to website X was ask if they were a 3Com shop, and if yes, reduce MTU.
Then there can be application specific issues. So VoIP on a network with no implicit congestion management/avoidance. Especially if that's by regulation and CoS/QoS is forbidden on the Internet because Net Neutrality. Or video. Mcasting was supposed to do that, but in no way scales to Netflix/YT like levels. Or had features a lot of content owners wanted, like control over subscribers. IPv6 isn't much better, but the Internet copes (thus far) because the solution is often to throw more bandwidth at the problem.