The problem turns out to be similar to IPv6, which is incompatible with the IPv4 that's historically been used. Running native IPv6 required end-to-end support, including your WiFi router, your Internet router (cable modem, DSL, etc.), your Internet provider, and the website. If a website only supported IPv6, there was no way for an IPv4 client to reach it. The early adoption solutions generally used tunneling like Teredo3. In Teredo, the client would create an IPv6 packet, then wrap it in IPv4 and deliver it to a "middlebox", which would extract the IPv6 payload and deliver it natively to the website.
Network coding could similarly be deployed using tunneling and a middlebox. The solution looks a little bit different, but the end result is the same: the client machine can use the advantages of the new protocol on the Internet in a way that's transparent to the local network and to the website.
Conceptually, I imagine that CTCP would be encapsulated using UDP between the client and the middlebox, since the primary advantage is reducing retransmissions on the client's local WiFi network. The middlebox would then L4 proxy the data stream to the end website, extracting the data transparently from the client CTCP and re-encoding it to the server's legacy TCP. In this sense, it's the opposite of Teredo: CTCP's value is the client-middlebox connection, and Teredo's value was the middlebox-server connection.
There are of course some difficulties in this scenario.
- Encapsulated traffic is difficult for firewalls to protect, as the real addressing info is buried inside a wrapper. Additionally, there may be L7 security concerns from HSTS, HTTP/2, etc., stemming from the recoding at L4 instead of L3.
- For graceful deprecation, what happens if CTCP becomes more common and some sites don't need a middlebox connection? How does the client recognize the difference and decide which connection to use?
- Google's QUIC protocol replaces TCP's congestion control and retransmissions with its own mechanism, which they claim is similarly designed to work with heavy packet loss. That would potentially remove the majority use case for CTCP
- CTCP is a trade secret, so there are financial and legal barriers in the way of widespread adoption.
Still, this would be a fun thing to prototype.
1. If you use your cell phone to tether when the WiFi is bad, don't tether via WiFi, as you're just adding more traffic to the already poor wireless spectrum, and even if it works for you, it makes the problem worse for everyone around you. If you have to tether, do it via USB (RNDIS on the PC), as it doesn't create more wireless traffic, and it lets your phone charge while you use it.↩
2. Coded TCP uses linear network encoding to spread payload data across multiple packets, so a lost packet can be reconstructed on the receiving end.↩
3. Teredo introduced some serious security problems, as it allowed IPv6 to bypass the firewall on the client's network, so it became best practice to turn it off. Ironically, many networks today which natively support IPv6 still don't apply firewall policy to the protocol, providing a similar level of insecurity.↩