> It is all a clever bit of design on the part of the MPTCP developers, but it also highlights an area of concern: the "dumb" Internet with end-to-end transparent routing of data is a thing of the distant past. What we have now is inflexible and somewhat hostile to the deployment of new technologies. The MPTCP developers have been able to work around these limitations, but the effort required was considerable. In the future, we may find that the net is broken in fundamental ways and it simply cannot be fixed; some might say that the difficulties in moving to IPv6 show that this has already happened.
The only problem is the lack of error reporting. For almost every other IT problem you can google error messages, extract log files,... on the other hand, the network is a complete black hole. The only way to fix this is a new name-and-shame technique or tool (let's call it "libMTR++").
The end-to-end principle cannot fight back in the dark, it has to KNOW where to hit in the first place.
- My Linux laptop had poor battery life. I ran PowerTOP. I reported "power bugs" and stopped using the wrong applications. Problem solved.
- My connection was bufferbloated (I could not video conference on it). I used MTR which pointed the problem at my mobile ISP. I switched to a different ISP. problem solved. (This is a *real story*!)
In the future:
- Gnutello5 (the new piece of software I want to use) depends on SCTP for some reason. Gnutello5 is not just using SCTP but also linked to "libMTR++". When connections time out the software does NOT just throw a generic and very poor "connection failed" message like it is doing now. Instead it offers the option to ask libMTR++ to perform a quick network trace/scan. Half of the time libMTR++ is able to return an informative error message pointing at *which subnet drops the packets*. Gnutello5 forums are flooded with messages saying "don't use this ISP". All Gnutello5 users switch ISP and other ISPs have to get their act together. Problem solved.
In the next few years IPv6 will be a great opportunity to test this "name-and-shame" approach. libMTR++ will not even be required for IPv6, "whatismyaddress.com" will be enough.