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.
Hi, On Fri, Jun 06, 2014 at 12:07:48PM -0400, Brian Rak 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.
only opt-in, please, if at all. Two of my probes are in production networks behind consumer DSL lines, and the people hosting them are going to be royally pissed if their links are saturated by other people's speed testing. (The third probe is in our datacenter, and won't be able to saturate it's link anyway - v1 probe and 100M link - so even for that one the test would not be exactly useful) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
On 2014.06.06. 19:32, Gert Doering wrote:
Hi,
On Fri, Jun 06, 2014 at 12:07:48PM -0400, Brian Rak 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.
only opt-in, please, if at all.
I'd say that if we do it (do enough people want this?) then it should only be possible to schedule this for your own probe, ie. if you're the host. I believe that's stronger than opt-in. And even then, we need to have a willing server side too (anchors?). Regards, Robert
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.
http://projectbismark.net/ already does this and I see no reason for RIPE Atlas to upset people by introducing this feature. Even if it is opt-in, confusion could arise easily enough. Iain. -- urn:x-human:Iain R. Learmonth http://iain.learmonth.me/ mailto:irl@fsfe.org xmpp:irl@jabber.fsfe.org tel:+447875886930 GPG Fingerprint: 1F72 607C 5FF2 CCD5 3F01 600D 56FF 9EA4 E984 6C49 Please verify out-of-band before trusting with sensitive information. This email was composed Fri 6 Jun 19:05:41 BST 2014.
On 06 Jun 2014, at 20:02, Robert Kisteleki <robert@ripe.net> wrote:
On 2014.06.06. 19:32, Gert Doering wrote:
On Fri, Jun 06, 2014 at 12:07:48PM -0400, Brian Rak 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.
only opt-in, please, if at all.
I'd say that if we do it (do enough people want this?)
Would be nice to have.
then it should only be possible to schedule this for your own probe, ie. if you're the host. I believe that's stronger than opt-in. .
One more possibility could be that only RIPE runs this test through the built-in measurements (perhaps a once a day or something). Allowing the possibility to run a speed test via a UDM exposes the risk of misuse as aforementioned.
And even then, we need to have a willing server side too (anchors?)
How about M-lab servers? Best, Vaibhav ----------------------------------------------------- Vaibhav Bajpai Research I, Room 86 Computer Networks and Distributed Systems (CNDS) Lab School of Engineering and Sciences Jacobs University Bremen, Germany www.vaibhavbajpai.com
brak@gameservers.com:
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.
My SEK 0.02 to the Atlas admin is plese don't go that way. That would be a very safe way to have me yank my probe out effective 0.1 seconds from me getting the news. While Atlas performs a very important and valuable service to the community - which is why I sacrify some of my precious personal bandwidth for it - I want to caution agains "death by testing". "Just because you can" is not a good reason to perform capacity tests. But if it can honestly be said "If $we only knew the performance stats from region X for service Y, then $we could easily and effectively improve the experience for all internet users (i.e., not only customers of said service) in that region by doing Y.", then a discussion would be welcome. Finding a suitable value of $we is essential, though. /Liman #---------------------------------------------------------------------- # Lars-Johan Liman ! E-mail: atlas@liman.net # Järneksvägen 19 ! Tel : 08 - 760 97 65 # 163 47 Spånga ! Mobil : 0708 - 54 06 66 #----------------------------------------------------------------------
On 7 June 2014 08:25, Lars-Johan Liman <atlas@liman.net> wrote:
brak@gameservers.com:
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.
My SEK 0.02 to the Atlas admin is plese don't go that way. That would be a very safe way to have me yank my probe out effective 0.1 seconds from me getting the news.
same here - my probe is on an expensive metered bandwidth line and I simply cannot allow even moderate probe usage, though I am happy for it to be used for anything else that does not incur me financial loss. Indeed the ISP I have connected the probe to is one of the best in the UK, if not the best, which is precisely why I have the probe on that line and not on others. The ISP on that line is an excellent high-quality, but this costs far more than a "normal" ISP, especially in peak daytime. The line is dedicated to VoIP and emergency use only due to the cost, with usage consistently 2GB per month, for a cost of around 50 Euro plus PSTN rental. Breaking through the 2.5GB barrier will add to the monthly cost and put me into the next price band upwards. The line is well worth the current cost because the ISP is brilliant and offers some unique advanced services, as well as IPv6 which is a requirement for me and very hard to find in the UK. I have a consumer-grade ISP at that site is unmetered, but performance is quite frankly terrible - a fact that may even skew result if bandwidth testing is introduced across the board. The consumer-grade ISP is heavily filtered, has CG--NAT, is oversubscribed and has terrible jitter and reliability with long engineering outages at ISP level, but it only costs 17 Euro a month (plus PSTN rental) for an "unlimited" service. It struggles with VoIP and video streaming, which get worse at peak times. "No Fault Found" is the ISP's report in response to fault-finding (that I was billed for) - this is simply normal service from the ISP in question. eg: I get far better perfomance metrics on my ADSL2+ high quality line than a consumer FTTC package at the same site, with cables in the same street bundle. Distance to the exchange for the ADSL2+ is twice (180m) the distance to the VDSL2 street cabinet 80m) yet the ADSL2+ line has faster download speeds from all servers by at least 20%, 24/7, than the VDSL2 80Mbps-down/20Mbps-up FTTC line it sits next to. Both lines consistently sync at max speed, and the FTTC uplink regularly gets 16Mbps real-world uplink rate, faster than the downlink :) This pattern is repeated across several sites for the same ISP on the FTTC connections, though the disparity varied according to which exchange the lines (all site have the same two 1x ADSL2+ and 1x VDSL2+) are connected to. All lines are short, because the premises were specially selected for proximity to the exchange. With unusual disparities between ISPs on similar lines like these examples, I fully agree there is a need for competent independent testing, especially of UK consumer-grade ISPs, just not on my Atlas probe on my expensive line ;) I deliberately have the probe connected to the high quality ISP because I know that the probe is connected to a reliable ISP that has no reachability issues, so it should prove a good reference for other probes on consumer lines in the UK. Anyone measuring download speed metrics on UK consumer-grade ISPs may be in for a surprise, but I don't believe that the Atlas project is the correct tool to do that. -- sent via Gmail web interface, so please excuse my gross neglect of Netiquette
On 6.06.14 18:07 , Brian Rak 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.
RIPE Atlas is not intended to be a last-mile bandwidth measuring tool. Atlas is about the network behind the first mile. There are others who do bandwidth very well, speedtest and samknows are among them. The last mile is not where the challenges of the future are and in many parts of the world it is not where the challenges are even now. Because of this Atlas is not designed to measure local connection bandwidth and hence it cannot do a good job at this. For example one of the connections at my house in a small village today has a downstream bandwidth of 180Mbit/s; the physical interface of the newest v3 probes is limited to 100Mbit/s; the v1 and v2 probes by far do not have the CPU to generate packets fast enough to saturate even their 100Mbit/s physical connections. Also we may irritate quite some hosts who have not signed up for their RIPE Atlas probe to use significant amounts of bandwidth. Some of the reactions on this list confirm that. All this is reason enough for us not to do "download speed" however great the temptation may be Daniel advisor to the RIPE Atlas team one of the "founders" of RIPE Atlas
On Sat, Jun 07, 2014 at 05:32:03PM +0200, Daniel Karrenberg wrote: [snip]
All this is reason enough for us not to do "download speed" however great the temptation may be
Yes. Also the whole "test to a server" portion being bogus; owners that wanted to build probe-to-probe testing would be potentially of value to the end-to-end Internet, but there are existing platforms for this. -- RSUC / GweepNet / Spunk / FnB / CotSG / Usenix / NANOG
Le 07/06/2014 21:26, Joe Provo a écrit :
On Sat, Jun 07, 2014 at 05:32:03PM +0200, Daniel Karrenberg wrote: [snip]
All this is reason enough for us not to do "download speed" however great the temptation may be
Yes.
Also the whole "test to a server" portion being bogus; owners that wanted to build probe-to-probe testing would be potentially of value to the end-to-end Internet, but there are existing platforms for this.
I agree with this. -- *Laurent Wattieaux* Tél : +33 6 86 67 62 30
Informations <http://info.laurent-wattieaux.com/> <<<
Blogger <http://info.laurent-wattieaux.com/blogger?utm_source=lien_Blogger_e-mail_Gapps&utm_medium=e-mail&utm_campaign=Gsites_Informations> / Google+ <http://info.laurent-wattieaux.com/google-plus?utm_source=lien_Gplus_e-mail_Gapps&utm_medium=e-mail&utm_campaign=Gsites_Informations> / Linkedin <http://info.laurent-wattieaux.com/linkedin?utm_source=lien_Linkedin_e-mail_Gapps&utm_medium=e-mail&utm_campaign=Gsites_Informations> / Skype <http://info.laurent-wattieaux.com/skype?utm_source=lien_Skype_e-mail_Gapps&utm_medium=e-mail&utm_campaign=Gsites_Informations> / Twitter <http://info.laurent-wattieaux.com/twitter?utm_source=lien_Twitter_e-mail_Gapps&utm_medium=e-mail&utm_campaign=Gsites_Informations>
On Jun 6, 2014, at 9:07 AM, Brian Rak <brak@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.
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@cisco.com> wrote:
On Jun 6, 2014, at 9:07 AM, Brian Rak <brak@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.
Hi, On Sat, Jun 07, 2014 at 07:46:26PM +0100, Colin Johnston wrote:
you could use ping time based on location distance of end point to destination.
RTT will tell you something about, well, RTT, but not very much about available bandwidth (while Fred's approach indeed will). I've seen 16Mbit ADSL lines with a higher RTT than 64kbit ISDN dialups... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
participants (12)
-
Bajpai, Vaibhav -
Brian Rak -
Colin Johnston -
Daniel Karrenberg -
Fred Baker (fred) -
Gert Doering -
Gord Slater -
Iain R. Learmonth -
Joe Provo -
Lars-Johan Liman -
Laurent Wattieaux -
Robert Kisteleki