[atlas] Speed tests?

you could use ping time based on location distance of end point to destination.


Sent from my iPhone

> On 7 Jun 2014, at 17:58, "Fred Baker (fred)" <fred at cisco.com> wrote:
> 
> 
>> On Jun 6, 2014, at 9:07 AM, Brian Rak <brak at gameservers.com> wrote:
>> 
>> Are there any plans to allow testing download speed from the probes?  I guess this could cause problems for people who have the probes on metered bandwidth plans.
> 
> There are several ways to do this, some of which might be less invasive than others. I don’t think we want any-to-any testing; another word for that is DDOS. But I could imagine bandwidth estimation based on the theory behind packet-pair. 
> 
> Packet-Pair depends on the observation that a bottleneck link moderates not only the speed of data that goes through it, but the speed of data that has gone through it and is observed somewhere else. If I send a burst of packets and receive a burst of acknowledgments, the interval between my receipt of acknowledgements is no shorter than, and likely to be comparable to, the interval between data arrivals at the far end. If I divide the amount an ack acknowledges by the interval since the previous acknowledgement, I get a data point that is related to the bandwidth of the bottleneck. It’s *just* a data point, and doesn’t tell me where the bottleneck is, but an accumulation of data points begin to tell a story.
> 
> Here’s one algorithm. Upstream, if the probe can determine that delay to a specified point (such as RIPE’s data center) were close to nominal (e.g., the path is relatively unused at the particular instant), it could open a TCP DISCARD session, send a burst of packets, observe the acks to get a data point, and close the session. That wouldn’t even require a proper TCP at the RIPE end; the system could use TCP cookies to prove that it wasn’t involved in an amplification attack, and respond to each permitted TCP data packet statelessly with an Ack packet. If we could agree on some message carried in it, such as a specified TCP option, the last data packet sent upstream could request a burst downstream, which it would observe as it arrived.
> 
> Just a thought.