A Networking Analogy
When you sit at your PC and work on the web (surf a web page for example), data packets flow across a large number of different elements, all which impact the throughput and latency you'll get.
Thinks of lots of different pipes bolted together to make one long pipe, from your PC to a web server in New York. These pipes are all of varying thickness, and therefore the pipe with the smallest diameter will restrict the water flow the most.
Now, these pipes start right there in your PC (lots and lots of different pipes, most of them software), then some network components, then the radio network, then more network components, lots of bits of kit that interconnect these pipes, also acting as pipes themselves, more pipes that leave the country, more pipes in the US and so on, till you hit the server, which has more pipes itself.
So you can see there are literally hundreds of connected pipes and you're trying to get a stream of water through all of these. "GPRS" will count as one of these pipes, in series with hundreds of others.
Not only is it obvious that the smallest pipe will become the biggest bottleneck but on most of these pipes multiple streams must be accommodated. Think of lots of little pipes inside one big pipe. Only one of these small pipes will carry your stream, let's call it 'shared pipes' or shared media. The number of small pipes (typically in network layer and up in the ISO model) can also increase or decrease (contention ratio) but can never exceed the total volume of the 'big' pipe (Phy and MAC layers) that contain them. This 'lots of small pipes in one big pipe' happens inside every pipe that serves multiple users, i.e. most of them.
The diameter of the pipe times the speed of water gives you the total flow (in litres / second). You can either make the pipe bigger (more bits) or use bigger pumps (higher clock frequency) to increase the flow.
Diameter x flow rate gives you 'throughput' but another, very important parameter is 'latency' (these two are often confused).
Let's say you start with all the pipes that connect you PC to the server empty. You then insert just one drop into the system. No single diameter should be less than the size of the drop so we can remove the thickness parameter. Yet you'll find the drop does not appear instantaneously at the server. Why not?
The speed of the drop is actually limited in each pipe by various factors. On the long, interconnecting pipes (back-haul links, for example), the speed is determined by the clock frequency of that link, say 10m/s or 100m/s. You'll agree that the higher the clock speed, the faster the drop will move.
Now the drop arrives at the first pumping station (router or other network element). It will be pumped into the engine at the same speed as the interconnecting pipe (otherwise pressure will start to build up), but then the poor drop get analyses more than a typical American gets probed by a Grey! This analysis might take some time and only when the pump station is done with the drop does it 'clock' it out onto the next pipe whose speed is again specific to that pipe (the clock frequency).
And so it goes, pipe - pump station - pipe - pump station, till it hits the server in New York after some time. This is called one-way latency. Now the server in NY send the same drop back to you and all the same time delays or latencies are incurred again before you get the drop back. You basically will see twice the one-way delay, called the round-trip delay or latency. (You've just done a one-drop ping!)
For one drop in the system this will be a fixed number.
You'll agree this is a pretty slow process and making the pipes bigger will have no impact on getting it there faster.
Now, let's say you want to send a bucket of water to New York (upload a file). If you had to do this drop by drop, inserting one drop at a time and waiting for the "I got your drop" acknowledgement to come back, before you send the next drop, it would take forever.
Rather what you'll do is to just pour the bucket of water into the first pipe!
The system will now fill up with the bucket of water and it will travel down the system as a 'bundle' of water, still individual drops, but tightly packed together filling up the width of all the pipes. On a big pipe the 'bundle' of water might only be a centimetre in thickness, while on a smaller pipe, it might be a few meters. But there are no gaps between the drops.
You'll agree that the first drop will still be delayed by the inherent latency of the system (the time it takes for one drop to reach NY), but the next drop will appear right on his bum with no time delay after the first drop.
The only thing that restricted the 'upload speed' was the thickness of the pipes x the size of the pumps. All drops saw the latency BUT AT THE SAME TIME.
So you can see that latency and throughput are different aspects.
If we could always trust the system to pump all the water across, we would do it this way, just chuck it in and forget about it.
Unfortunately we cannot. The systems are not failsafe, you might loose drops along the way.
To accommodate this we introduce a concept of 'handshaking' where we acknowledge receiving a number of drops every now and then. The system sending the water will now be ensured the water is actually delivered and there are no holes in the pipes along the way.
The most reliable but worst in performance would be to get a response drop back for every drop you send. In other words; You send one drop and then wait to hear (by return drop) that the drop was actually received. Then you send the next one, etc. This would be extremely slow but sometimes it is done (think Telnet).
Chucking all the water in at once, will give the best throughput but if you loose one drop, you have to resend everything.
A better solution would be to guess the reliability of the system and pick a number of drops to send as a single stream before you wait for an OK drop. Lets say we pick a thousand drops. Now you send a thousand drops and then stop and wait for the return drop. If you receive it and all is OK, you send the next 1000 drops. If not you resend the first 1000 drops (You kept a copy!).
The problem with this concept is we have now introduced latency again! Only the first drop saw the latency but then we stop and wait for the return drop (which incurs the same latency) then we start up again and again the first drop sees the latency.
So although we can have a high throughput (diameter x pump rate), every 1000 drops we stop and then have to start all over again.
Obviously we want to make this number as large as possible but it is always a trade off. If we make it too big, and we loose 1 drop, we have to resend a large number of drops and the effective throughput suffers. If we make it too small (and we never loose drops) we introduce unnecessary latency.
So we would like to choose this number and often (like in TCP) we can. It's called the 'sliding window'. The bigger the 'window' the more drops are sent before we wait. Sometimes the systems are even clever enough to change it on the fly.
The problem is (as always), all these different pipes. A reliable pipe might only require a sliding window of a 1000 while an unreliable pipe might need 10. So you always need to run at some compromise.
OK, so we've discussed three concepts:
1) Number of network elements in the link and if they're dedicated or shared (contended)
2) Latency (how long does it take one drop to travel down the system)
3) Throughput (how many drops can it carry at any one time)
(A 4th concept you need to understand which we did not discuss in this analogy, is that of the peer-to-peer nature of protocol stacks, where one layer will only communicate with it's corresponding layer. It's extremely important to understand as each layer effectively implements the whole scenario described here)
So in a system where many of the pipes are not under your control (you cannot control diameter, pump speed, delays or number of streams) there is no way you can guarantee the final water flow rate. So you can only provide a 'best effort'.
A pipe provider might be able to guarantee a specific pipe which is easy if you control all the aspects of the pipe. For example, one time-slot on a GPRS link will give a fixed throughput. Lower than that it'll actually break and stop working altogether. Or a diginet link between two points (say Cape Town and JHB) will always have the same speed (clock), thus throughput. This is what TT implied. But the moment one of these becomes a link in a much longer chain, there can be no end-to-end guarantees.
So when you sit at your PC and you do a speed test, all you do is to mostly measure the throughput of the 'thinnest' pipe in the chain of pipes. Even if you know a specific pipe in the string is bigger than what you're measuring, it will not improve the test result as its impact will be very small.
You also need to understand the concepts above as these will impact your test results but often in a way you can't determine as it's 'hidden' in the system itself.
For example what were all the 'pipes' in the test, what was the latency and throughput of each, what was the contention on each of them and what was the overall management overhead of the end-to-end test.
