What is the Transport Protocol Used in wget?

This is a very complicated process, so to formulate an equation that could be useful for accurately predicting RTTs is extremely difficult. At best, I would say you could create a model that using a bunch of averages for each stage, that you could tweak if you happen to "know better" for a particular situation is about as close as you can get. This is something I am presently studying so I can tell you what I know so far (from the ground up, starting at the physical layer):

• See my questions on the Electronics SE; Encoding delay of Ethernet and the relation to cable frequency rating and Speed of electricity (signal propagation?) through copper for communications delay. Since you would be using standardised speeds (100Mbps, 1Gbps, 10Gbps etc), don't treat fibre or copper differently. The "delay" down the two is near as damn it the same, but copper can't carry a signal as far obviously. I have this question on the Physics SE site, which I do know the answer to now. I just need to find the time to right it up, so keep an eye on that if you are interested (I will be posting some more telecoms-use-of-fibre related questions to which I now know the answer when I get a chance).

• Much more delay is going to be added in by the devices at the end of a link. There is no standard way of saying "oh 2 switches along a path is Xms delay, 4 switches is 2*Xms, 2 routers is Yms...etc". Assuming you are using say 1Gpbs for example and the devices in the path forward at line rate, we know that is 1000000000bps, so the physical interface is running at a fixed encoding rate (ranging from 1 nanosecond per bit up to whatever the max of the symbol encoding scheme in use is, such as 10b)

• There are three main kinds of delay (at the physical layer) you need to be aware of and factor in; Serialisation delay, encoding delay, propagation delay (and processing delay, queueing delay, encode and decoding delay, but these are above the physical layer but need mentioning!). These are reasonably well documented on the Internet, VoIP: An In-Depth Analysis, Slide 13 here, loads on Google Scholar, and many more.

• As we move up the protocol stack, I would work on the assumption that the destination MAC is in each switches cam table, and at the IP layer, the destination MAC in ARP tables. The extra delay induced by these discovery processes only occurs for the first packet in a flow so they can be circumvented by raising time-outs and sending gratuitous ARPs etc.

• As you get to the application layer this is going to get really difficult because this depends on the server (for example) processing the request, which will be subject to interrupt delay. The number of interrupts required to process the request and context switches due to load is unpredictable.

I would very much like to help you with your question, sadly this is all I have time for right now. I will update this answer maybe later tonight or tomorrow, I wanted to post what I have so far.

In the mean time, most people tend to work with the figure for the delay at a physical copper/fibre layer of around 0.6*c (C = speed of light). Also, you need to think about TCP's exchange of ACKs every X packets, which differs if you are using SACK for example, and if you're using jumbo frames and/or larger MSS size (now MTU needs to be factored in also!), if you're sending more in-between ACKs (if volume of data transferred is of interest to you). You also need to factor in the infamous Bandwidth Delay Product and don't make the stupid misinterpretation that I did of that page. I started making various simple (and very ugly) data calculators here. Again a work in progress I will try and update them soon. I plan to add a calculator similar to what you are trying to do. I have also made some light and fibre calculators if you are interested, but again, no time!, I haven't gotten round to uploading them yet. I will try ASAP to update this answer some more, in the coming days.

P.S. I forgot to mention QoS! If QoS is in play anywhere in the path, it's going to get really tough to caluclate the RTT!

1. What goes into setting the MSS?

In the question you referenced it stated this, the MSS is derived directly from MTU. A typical Ethernet MTU will 1500, but IP and TCP headers must also be taken into account - each of them are 20 bytes.

Note: Just an FYI, MTU can be different sizes - see Jumbo Frames for an example.

We end up with:

MSS = 1500 - 20 - 20
MSS = 1460 bytes of TCP data

I'd like to emphasize something you mentioned, you are 100% correct in stating that the MSS for the TCP connection is established during the 3 way handshake. Should either side of the connection want to adjust its MSS, the TCP connection would have to be torn down and re-established. Before going any further, we need to clarify that a "receive MSS", what you're thinking of is the TCP receive window. This is not the same as the MSS.

2. Do other factors go into the calculation of one side's MSS?

So remember, the TCP MSS is established during the TCP handshake along with all of the other session options. The vast majority of the time the agreed upon MSS will be the largest possible payload that can be sent in a TCP segment without fragmentation. The last part is key, this means if a client and server are trying to establish a TCP connection, and the client has a smaller MSS size set, the connection will choose the smaller of the two values to avoid said fragmentation.

As it should be noted, it is possible to manually set MSS if whoever is running the application/service doesn't care about fragmentation.

3. What factors does a Client or Server use when they state "I want you to send me TCP segments in maximum chunks of X bytes?" Is it solely based upon the MTU?

The bottom line is that TCP will try to squeeze as much data into each message as it can to maximize network efficiency. To be clear, a single un-fragmented TCP segment's payload (headers, data, options, etc.) CANNOT exceed than that of the MSS, if that single TCP segment is one message, or a piece of a fragmented one is irrelevant to TCP - that's what it's designed to handle.

It's not solely based on MTU of the end hosts, but as previously mentioned it is derived from it. Things like a lower "Path MTU" (see Path MTU Discovery (PMTUD)), can affect network performance.

Other factors can affect network performance as well, but not necessarily only MSS. You can check out things like TCP Tuning, if you'd like an idea of what else you might think about when designing an application or service around TCP.