Absolute speedup is difficult to quantify due to the many other factors involved, but current TCPs approach the maximum theoretical throughput (when all overheads are taken into account).
Experimental. This is mainly observation of the dumps and the identification of the various trends.
Experimental. We would hope the experiments bear out the theory. If not, it would be interesting to speculate why.
There are plenty of papers on comparison of the TCP variants. For example see here, here and here for just a few that Google finds.
Reno variants seem to be the most commonly implemented.
Clearly the timeouts need to be adjusted. For example, in the ACK we should start with a timeout comparable to the estimated round trip time. Quite how we specify this or even estimate this is open. As round trip times vary (e.g., 3 to 22 minutes) we might want to base our initial timeout on the relative positions of the planets. Or have some separate protocol that periodically measures RTTs (via pings?) and passes the information to TCP.
Also, the connection is a huge LFN, so the issues for long fat pipes (window sizes, wrapped sequence numbers, etc.) are correspondingly large.
The Consultative Committee for Space Data Systems (CCSDS) has some information on this topic, with recommendations for the Space Communications Protocol Specification (SCPS) Transport Protocol (SCPS-TP). Also here and here.
These days, ECN corrupt routers are thankfully rare.
Experimental. As these tools send a lot of data to get accurate results, make sure that you have permission to probe the remote machines. Otherwise they may regard the probes as hostile attacks!
Experimental. Likely this will be a trans-oceanic link (e.g., UK to USA across the Atlantic), or perhaps a satellite link (more unusual these days). You can modify the TOS bits on the pings, which may encourage routers to send via slower, bulk data routes including satellite links.
The major problem is that T/TCP allows spoofing: data is sent before sequence numbers are fully negotiated, so an attacker could masquerade as a trusted client and have its data accepted before the server has had a confirming ACK from the real client. See here for this and other problems.
Another issue with T/TCP is that the client wants to send data to the server (in the SYN segment) before it knows how large a window the server has.
SCTP retains the parts that make TCP successful (packet retransmission, congestion avoidance algorithms and so on), and builds on it (unordered reliable delivery, multiple streams in a connection and so on), providing facilities that our experience with TCP have shown would be useful.
This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 License.