Your ISP doesn't and cannot control those sites' infrastructure, though. So any guarantees they make would have to make assumptions about the huge number of variables beyond their control. For example, the quality of your equipment, the number of users and types of applications you're using, the quality and line use of your local exchange and/or neighbours, the quality and load of the infrastructure exiting your ISP's network, the condition of and load of third party infrastructure that may be used forwarding messages from your ISP's network to the destination, the possibility of crossing large distances (possibly across continents or oceans), the quality of the destination host's infrastructure, the current load of the destination's server(s), the internal speed at which your request can be properly satisfied, and then everything I've mentioned in reverse so the responses are sent back to you, [i]and then[/i] how long your device takes to process the responses. There are so many variables at play that estimating the speed is only going to be somewhat accurate if you can make near-absolute assumptions (or have the foreknowledge) about the state of every device and medium along the network path (and that's even assuming you could know which path your messages take) and the devices and applications being used (ie. when assessing "speed" are we looking at host-to-host "link speed", end-to-end speed, or the speed at which the user perceives it?).