Sean,

Your just trying to choose reasonable timeouts for your TCP packets? Well, why didn't you say so? (Or perhaps I missed it). 

Fortunately, Einstein's General Theory of Relativity was solved long ago, so that's take care of. 🙂

If you're trying to choose reasonable timeouts, a wrong question to ask is "What is the current diameter of the Internet?" No matter what the diameter is, whether measured in RTT or TTL hops, a more useful question is, "How long am I willing to wait before considering a packet lost and retransmitting?" That time doesn't really matter so much on modern networks, so just choose a nice value you can live with, such as an hour (which happens to be the default). The timeout field itself can record values up to one day, so someone apparently thought that might be useful sometime (see RFC2549). 

Keep in mind that  TCP rarely is configured to acknowledge each packet before sending the next. Instead it expects an acknowledgement every so-many packet.

Consider the deminimus thought experiment. Your packet timeout is set to 2000 ms (two seconds). In the midst of an existing TCP session, you fire a slew of TCP packets – enough to fill your Send Window, and then wait for an ACK. Before you know it, 2000 ms has elapsed, and under TCP rules, you must consider those packets "lost". So, you retransmit them. But then, at 2035 ms, you receive the presumed missing ACK, which indicates all your packets were received at the far end after all. No harm done, because the far end will just treat the retransmissions as duplicates and throw them away. 

The amount of delay a packet experiences has a lot less to do with the distance, diameter, or latency, and a lot more to do with the processing going on along the way. For example, a router becomes congested, and hangs on to packets longer than usual. The congestion spreads along the path your packets are taking, so the delay adds up.

In the end, unless you're using some really unusual technology (e.g. RFC2549), just set the timeout to the default 3600 seconds (1 hour). For a detailed explanation, refer to Richard Stevens TCP/IP Illustrated, Chapter 14 .TCP Timeout and Retransmission.

 -mel