From jice at igwan.net Sun Jun 1 19:39:44 2014 From: jice at igwan.net (JC) Date: Sun, 01 Jun 2014 14:39:44 -0300 Subject: [atlas] Probe not showing IPv6 ASN and subnet on map Message-ID: Hi, We just setup our probe (id: 17328) and configured static IPv6 on it. Built-in measurements to IPv6 destinations seems to perform correctly from this probe. However, when we display detailed information about the probe on the coverage map https://atlas.ripe.net/results/maps/network-coverage/ we only see IPv4 information and no IPv6 subnet or ASN. Besides, searching for our IPv6 ASN (21538) in the filter field brings no results. Thanks for your help. Regards, JC From robert at ripe.net Mon Jun 2 14:52:13 2014 From: robert at ripe.net (Robert Kisteleki) Date: Mon, 02 Jun 2014 14:52:13 +0200 Subject: [atlas] Probe not showing IPv6 ASN and subnet on map In-Reply-To: References: Message-ID: <538C737D.3070203@ripe.net> On 2014.06.01. 19:39, JC wrote: > Hi, > > We just setup our probe (id: 17328) and configured static IPv6 on it. > Built-in measurements to IPv6 destinations seems to perform correctly from > this probe. > > However, when we display detailed information about the probe on the > coverage map https://atlas.ripe.net/results/maps/network-coverage/ we only > see IPv4 information and no IPv6 subnet or ASN. > Besides, searching for our IPv6 ASN (21538) in the filter field brings no > results. > > > > Thanks for your help. > > Regards, > > JC Hi, There seems to be a local configuration problem. We'll contact you offline about the details. Regards, Robert From BECHA at ripe.net Tue Jun 3 14:19:33 2014 From: BECHA at ripe.net (Vesna Manojlovic) Date: Tue, 03 Jun 2014 14:19:33 +0200 Subject: [atlas] Changes to the Distribution Model for RIPE Atlas Probes Message-ID: <538DBD55.5060300@ripe.net> Dear colleagues, we have made some adjustments in the distribution model of RIPE Atlas probes to ensure wider topological and geographical probe coverage. Please read more in this RIPE Labs article: https://labs.ripe.net/Members/fatemah_mafi/changes-to-the-distribution-model-for-ripe-atlas-probes Regards, Vesna From mgalante at ripe.net Tue Jun 3 14:42:03 2014 From: mgalante at ripe.net (Michela Galante) Date: Tue, 3 Jun 2014 14:42:03 +0200 Subject: [atlas] RIPN (RU) has joined RIPE Atlas anchors Message-ID: Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called ru-mow-as15835 and it is hosted by RIPN in Moscow, Russia. Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind regards, Measurements Community Building Team RIPE NCC mcb at ripe.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2612 bytes Desc: not available URL: From bortzmeyer at nic.fr Tue Jun 3 17:37:59 2014 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 3 Jun 2014 17:37:59 +0200 Subject: [atlas] A collection of tools in Perl Message-ID: <20140603153759.GA28239@laperouse.bortzmeyer.org> https://github.com/pierdom/atlas-toolbox From daniel.karrenberg at ripe.net Wed Jun 4 15:16:41 2014 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 04 Jun 2014 15:16:41 +0200 Subject: [atlas] Automatic Geolocation by ping RTT anyone? In-Reply-To: <20140603153759.GA28239@laperouse.bortzmeyer.org> References: <20140603153759.GA28239@laperouse.bortzmeyer.org> Message-ID: <538F1C39.6000401@ripe.net> On 3.06.14 17:37 , Stephane Bortzmeyer wrote: > https://github.com/pierdom/atlas-toolbox This toolbox looks like it is just made for geolocating an address by automating a series of geographically more and more restricted atlas ping measurements. Has anyone already done that and is willing to share? Lazily yours ;-) Daniel From emile.aben at ripe.net Wed Jun 4 23:04:09 2014 From: emile.aben at ripe.net (Emile Aben) Date: Wed, 04 Jun 2014 23:04:09 +0200 Subject: [atlas] Automatic Geolocation by ping RTT anyone? In-Reply-To: <538F1C39.6000401@ripe.net> References: <20140603153759.GA28239@laperouse.bortzmeyer.org> <538F1C39.6000401@ripe.net> Message-ID: <538F89C9.2070700@ripe.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 04/06/14 15:16, Daniel Karrenberg wrote: > On 3.06.14 17:37 , Stephane Bortzmeyer wrote: >> https://github.com/pierdom/atlas-toolbox > > > This toolbox looks like it is just made for geolocating an address > by automating a series of geographically more and more restricted > atlas ping measurements. > > Has anyone already done that and is willing to share? I worked with the team behind the Spotter project ( http://lakis.web.elte.hu/publ/laki_infocom2011.pdf ) to give this a try on RIPE Atlas, but nothing came of that. Big problem is first mile latency. I do have prototype code for something like this in OpenIPMap, but it's currently not used because it doesn't perform too well. Happy to share (it's embedded in django models) and hope you can improve. cheers, Emile > > Lazily yours ;-) > > Daniel > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlOPickACgkQj05ACITZaqqCbAEAk5/wc3g9NghE2DzEqM49BxZ/ rVs/P65G8QzCH6oE88IA/i42UhI1Fsz22lLg9GNWnCR3ulfPONr2xBE2xSVgGqyD =f310 -----END PGP SIGNATURE----- From mgalante at ripe.net Fri Jun 6 13:41:26 2014 From: mgalante at ripe.net (Michela Galante) Date: Fri, 6 Jun 2014 13:41:26 +0200 Subject: [atlas] NTT Communications (US, Seattle and Atlanta) have joined RIPE Atlas anchors Message-ID: <19232D7B-CF21-4133-A3D1-71771A5F18ED@ripe.net> Dear RIPE Atlas users, We're happy to announce that two more RIPE Atlas anchors have joined the network and are now available as targets for probe hosts conducting their own user-defined measurements. The new anchors, both hosted by NTT Communications in United States, are: us-sea-as2914, in Seattle us-atl-as2914, in Atlanta Congratulations to NTT Communications for their third and forth anchor online! Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards these anchors from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind regards, Measurements Community Building Team RIPE NCC mcb at ripe.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2612 bytes Desc: not available URL: From mail at johnbond.org Fri Jun 6 17:23:07 2014 From: mail at johnbond.org (john) Date: Fri, 06 Jun 2014 17:23:07 +0200 Subject: [atlas] Empty from feild Message-ID: <5391DCDB.7060105@johnbond.org> Hello All, Quick question about the data format. What would cause a measurement to have an empty from field but contain data? An example would be probe_id 13663 from measurement 1672218[1]. A cursory glance seems to happens a lot more with V6 Thanks John [1]https://atlas.ripe.net/api/v1/measurement-latest/1672218/ From philip.homburg at ripe.net Fri Jun 6 17:36:10 2014 From: philip.homburg at ripe.net (Philip Homburg) Date: Fri, 06 Jun 2014 17:36:10 +0200 Subject: [atlas] Empty from feild In-Reply-To: <5391DCDB.7060105@johnbond.org> References: <5391DCDB.7060105@johnbond.org> Message-ID: <5391DFEA.5070007@ripe.net> Hi, On 2014/06/06 17:23 , john wrote: > Quick question about the data format. What would cause a measurement to > have an empty from field but contain data? An example would be probe_id > 13663 from measurement 1672218[1]. A cursory glance seems to happens a > lot more with V6 The 'from' field is the address of the probe as recorded by the controller (as opposed to what the probe reports itself as 'src_addr'). The controller takes it from the ssh connection. A probe that has both v4 and v6 tries to initiate two ssh connections, one over v4 and one over v6. If one of them fails, then it is possible that the probe connects but the controller doesn't know the IP address of the one that fails. Philip From inigo at infornografia.net Fri Jun 6 17:35:49 2014 From: inigo at infornografia.net (=?UTF-8?Q?I=C3=B1igo_Ortiz_de_Urbina?=) Date: Fri, 6 Jun 2014 17:35:49 +0200 Subject: [atlas] Empty from feild In-Reply-To: <5391DCDB.7060105@johnbond.org> References: <5391DCDB.7060105@johnbond.org> Message-ID: Hi John, all On Fri, Jun 6, 2014 at 5:23 PM, john wrote: > Hello All, > > Quick question about the data format. What would cause a measurement to > have an empty from field but contain data? An example would be probe_id > 13663 from measurement 1672218[1]. A cursory glance seems to happens a > lot more with V6 Seems like the API is missing the probe's v4 info (prefix and addr) [1], even though it is not a v6-only probe since it does indeed report measurement results for msm 1672218. If the backends where all this data is being pulled from do not have that bit of information, it cannot be used in any API at all, other than having its value set to null or an empty string. I've seen this happening before but I don't have an explanation for it. Hopefully, devs might be able to shed some light as to why some probes cannot report their IP addresses. > Thanks John > > [1]https://atlas.ripe.net/api/v1/measurement-latest/1672218/ > I?igo [1] https://atlas.ripe.net/api/v1/probe/13663/?format=json -- "If you want to go fast, go alone. If you want to go far, go together." From mail at johnbond.org Fri Jun 6 17:46:38 2014 From: mail at johnbond.org (john) Date: Fri, 06 Jun 2014 17:46:38 +0200 Subject: [atlas] Empty from feild In-Reply-To: <5391DFEA.5070007@ripe.net> References: <5391DCDB.7060105@johnbond.org> <5391DFEA.5070007@ripe.net> Message-ID: <5391E25E.9040703@johnbond.org> On 06/06/14 17:36, Philip Homburg wrote: > Hi, > > On 2014/06/06 17:23 , john wrote: >> Quick question about the data format. What would cause a measurement to >> have an empty from field but contain data? An example would be probe_id >> 13663 from measurement 1672218[1]. A cursory glance seems to happens a >> lot more with V6 > > The 'from' field is the address of the probe as recorded by the > controller (as opposed to what the probe reports itself as 'src_addr'). > > The controller takes it from the ssh connection. A probe that has both > v4 and v6 tries to initiate two ssh connections, one over v4 and one > over v6. If one of them fails, then it is possible that the probe > connects but the controller doesn't know the IP address of the one that > fails. Thanks for the explanation. would it be possible to also expos the src_addr through sagan? Thanks John From philip.homburg at ripe.net Fri Jun 6 17:58:02 2014 From: philip.homburg at ripe.net (Philip Homburg) Date: Fri, 06 Jun 2014 17:58:02 +0200 Subject: [atlas] Empty from feild In-Reply-To: <5391E25E.9040703@johnbond.org> References: <5391DCDB.7060105@johnbond.org> <5391DFEA.5070007@ripe.net> <5391E25E.9040703@johnbond.org> Message-ID: <5391E50A.9020005@ripe.net> On 2014/06/06 17:46 , john wrote: > Thanks for the explanation. would it be possible to also expos the > src_addr through sagan? It is there, it is just spelled differently (source_address) Philip From brak at gameservers.com Fri Jun 6 18:07:48 2014 From: brak at gameservers.com (Brian Rak) Date: Fri, 06 Jun 2014 12:07:48 -0400 Subject: [atlas] Speed tests? Message-ID: <5391E754.3070609@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. From gert at space.net Fri Jun 6 19:32:31 2014 From: gert at space.net (Gert Doering) Date: Fri, 6 Jun 2014 19:32:31 +0200 Subject: [atlas] Speed tests? In-Reply-To: <5391E754.3070609@gameservers.com> References: <5391E754.3070609@gameservers.com> Message-ID: <20140606173231.GJ46558@Space.Net> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From robert at ripe.net Fri Jun 6 20:02:20 2014 From: robert at ripe.net (Robert Kisteleki) Date: Fri, 06 Jun 2014 20:02:20 +0200 Subject: [atlas] Speed tests? In-Reply-To: <20140606173231.GJ46558@Space.Net> References: <5391E754.3070609@gameservers.com> <20140606173231.GJ46558@Space.Net> Message-ID: <5392022C.70003@ripe.net> 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 From irl at fsfe.org Fri Jun 6 20:07:11 2014 From: irl at fsfe.org (Iain R. Learmonth) Date: Fri, 6 Jun 2014 19:07:11 +0100 Subject: [atlas] Speed tests? In-Reply-To: <5392022C.70003@ripe.net> References: <5391E754.3070609@gameservers.com> <20140606173231.GJ46558@Space.Net> <5392022C.70003@ripe.net> Message-ID: <20140606180711.GA8050@orbiter> > >> 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 at fsfe.org xmpp:irl at 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From v.bajpai at jacobs-university.de Fri Jun 6 20:21:19 2014 From: v.bajpai at jacobs-university.de (Bajpai, Vaibhav) Date: Fri, 6 Jun 2014 18:21:19 +0000 Subject: [atlas] Speed tests? In-Reply-To: <5392022C.70003@ripe.net> References: <5391E754.3070609@gameservers.com> <20140606173231.GJ46558@Space.Net> <5392022C.70003@ripe.net> Message-ID: <3B07C7FF-D17F-4FED-8DC6-151F3B90B3D7@jacobs-university.de> On 06 Jun 2014, at 20:02, Robert Kisteleki 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From atlas at liman.net Sat Jun 7 09:25:25 2014 From: atlas at liman.net (Lars-Johan Liman) Date: Sat, 07 Jun 2014 09:25:25 +0200 Subject: [atlas] Speed tests? In-Reply-To: <5391E754.3070609@gameservers.com> (Brian Rak's message of "Fri, 06 Jun 2014 12:07:48 -0400") References: <5391E754.3070609@gameservers.com> Message-ID: <22a99pp4ey.fsf@dhcp-249.liman.net> brak at 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 at liman.net # J?rneksv?gen 19 ! Tel : 08 - 760 97 65 # 163 47 Sp?nga ! Mobil : 0708 - 54 06 66 #---------------------------------------------------------------------- From daniel.karrenberg at ripe.net Sat Jun 7 17:32:03 2014 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Sat, 07 Jun 2014 17:32:03 +0200 Subject: [atlas] Speed tests? In-Reply-To: <5391E754.3070609@gameservers.com> References: <5391E754.3070609@gameservers.com> Message-ID: <53933073.1060908@ripe.net> 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 From fred at cisco.com Sat Jun 7 18:58:23 2014 From: fred at cisco.com (Fred Baker (fred)) Date: Sat, 7 Jun 2014 16:58:23 +0000 Subject: [atlas] Speed tests? In-Reply-To: <5391E754.3070609@gameservers.com> References: <5391E754.3070609@gameservers.com> Message-ID: On Jun 6, 2014, at 9:07 AM, 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. 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: Message signed with OpenPGP using GPGMail URL: From colinj at mx5.org.uk Sat Jun 7 20:46:26 2014 From: colinj at mx5.org.uk (Colin Johnston) Date: Sat, 7 Jun 2014 19:46:26 +0100 Subject: [atlas] Speed tests? In-Reply-To: References: <5391E754.3070609@gameservers.com> Message-ID: 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)" wrote: > > >> On Jun 6, 2014, at 9:07 AM, 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. > > 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. From gordslater at gmail.com Sat Jun 7 21:22:34 2014 From: gordslater at gmail.com (Gord Slater) Date: Sat, 7 Jun 2014 20:22:34 +0100 Subject: [atlas] Speed tests? In-Reply-To: <22a99pp4ey.fsf@dhcp-249.liman.net> References: <5391E754.3070609@gameservers.com> <22a99pp4ey.fsf@dhcp-249.liman.net> Message-ID: On 7 June 2014 08:25, Lars-Johan Liman wrote: > brak at 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 From gert at space.net Sat Jun 7 21:22:38 2014 From: gert at space.net (Gert Doering) Date: Sat, 7 Jun 2014 21:22:38 +0200 Subject: [atlas] Speed tests? In-Reply-To: References: <5391E754.3070609@gameservers.com> Message-ID: <20140607192238.GR46558@Space.Net> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From jzp-ripeatlas at rsuc.gweep.net Sat Jun 7 21:26:13 2014 From: jzp-ripeatlas at rsuc.gweep.net (Joe Provo) Date: Sat, 7 Jun 2014 15:26:13 -0400 Subject: [atlas] Speed tests? In-Reply-To: <53933073.1060908@ripe.net> References: <5391E754.3070609@gameservers.com> <53933073.1060908@ripe.net> Message-ID: <20140607192613.GA96521@gweep.net> 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 From mgalante at ripe.net Tue Jun 10 15:38:51 2014 From: mgalante at ripe.net (Michela Galante) Date: Tue, 10 Jun 2014 15:38:51 +0200 Subject: [atlas] Lemuria Communications (US) has joined RIPE Atlas anchors Message-ID: <33D66C84-69E8-4832-BA7E-3B66425C8D2F@ripe.net> Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called us-dal-as7366 and it is hosted by Lemuria Communications in Dallas, United States. Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind regards, Measurements Community Building Team RIPE NCC mcb at ripe.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2612 bytes Desc: not available URL: From laurent at laurent-wattieaux.com Wed Jun 11 09:26:50 2014 From: laurent at laurent-wattieaux.com (Laurent Wattieaux) Date: Wed, 11 Jun 2014 09:26:50 +0200 Subject: [atlas] Speed tests? In-Reply-To: <20140607192613.GA96521@gweep.net> References: <5391E754.3070609@gameservers.com> <53933073.1060908@ripe.net> <20140607192613.GA96521@gweep.net> Message-ID: <539804BA.8040401@laurent-wattieaux.com> 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 <<< Blogger / Google+ / Linkedin / Skype / Twitter -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: collect Type: image/gif Size: 35 bytes Desc: not available URL: From Ondrej.Caletka at cesnet.cz Wed Jun 11 12:03:37 2014 From: Ondrej.Caletka at cesnet.cz (=?UTF-8?B?T25kxZllaiBDYWxldGth?=) Date: Wed, 11 Jun 2014 12:03:37 +0200 Subject: [atlas] Selecting only anchors for UDM Message-ID: <53982979.9030606@cesnet.cz> Hello list, is there a way to run an UDM on Anchors only? I think it would be a good feature, especially for precise latency measurement. Cheers, Ond?ej Caletka -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5563 bytes Desc: Elektronicky podpis S/MIME URL: From daniel.karrenberg at ripe.net Wed Jun 11 12:25:05 2014 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 11 Jun 2014 12:25:05 +0200 Subject: [atlas] Selecting only anchors for UDM In-Reply-To: <53982979.9030606@cesnet.cz> References: <53982979.9030606@cesnet.cz> Message-ID: <53982E81.3000803@ripe.net> On 11.06.14 12:03 , Ond?ej Caletka wrote: > Hello list, > > is there a way to run an UDM on Anchors only? I think it would be a good > feature, especially for precise latency measurement. > > Cheers, > Ond?ej Caletka > Yes, that would be useful. I have been programming around this using the API to fetch the whole probe list first. I suggest an API extension to select probe types that is exposed in the UI : "probes": [ { "requested": 10, "type": "area", "probetype": "anchor", "value": "WW" } ] This is nicely general. One could later add probetypes like: "hasipv6" and "hardwarev3". If that is too much an extension a la "probes": [ { "requested": 10, "type": "anchor", "value": "WW" } ] would already help. Can we put that on the road-map? Anyone else who would like this in the UI and API? Daniel From astrikos at ripe.net Wed Jun 11 12:25:39 2014 From: astrikos at ripe.net (Andreas Strikos) Date: Wed, 11 Jun 2014 12:25:39 +0200 Subject: [atlas] Selecting only anchors for UDM In-Reply-To: <53982979.9030606@cesnet.cz> References: <53982979.9030606@cesnet.cz> Message-ID: <53982EA3.2070105@ripe.net> Hi Ond?ej, there is already an API only flag that is similar to what you want. Its behavior is a bit different from what you want though, since it will try to fetch anchors first and if we don't have enough the rest will be covered by normal probes. Would that be sufficient for your needs? It's not stated on the docs and we use it currently only for our internal needs. It makes sense now though to give it to public as well. There is some cleaning up to be done first so it will be out with one of our next releases. Regards, Andreas On 6/11/14, 12:03 PM, Ond?ej Caletka wrote: > Hello list, > > is there a way to run an UDM on Anchors only? I think it would be a good > feature, especially for precise latency measurement. > > Cheers, > Ond?ej Caletka > From ripe at antoin.nl Wed Jun 11 13:16:21 2014 From: ripe at antoin.nl (Antoin Verschuren) Date: Wed, 11 Jun 2014 13:16:21 +0200 (CEST) Subject: [atlas] Selecting only anchors for UDM In-Reply-To: <53982E81.3000803@ripe.net> References: <53982979.9030606@cesnet.cz> <53982E81.3000803@ripe.net> Message-ID: On Wed, 11 Jun 2014, Daniel Karrenberg wrote: > Can we put that on the road-map? Anyone else who would like this in the > UI and API? I would sugest to use the probe tags for this. RIPE could give the anchors a tag that can not be selected through the UI, but unfortunately, you can create your own tag as well ;-) Sometimes you would want to measure only with probes that are deployed at the core of networks, and sometimes you would only want edges, i.e. probes installed in peoples homes. The tags could be a nice selection criteria for the type of probes you'd like to use. This all depends on the accuracy of the probe owner selecting the tags though, but some tags like anchor or hasipv6 could be filled automagicaly. Antoin From robert at ripe.net Wed Jun 11 14:07:55 2014 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 11 Jun 2014 14:07:55 +0200 Subject: [atlas] Selecting only anchors for UDM In-Reply-To: References: <53982979.9030606@cesnet.cz> <53982E81.3000803@ripe.net> Message-ID: <5398469B.6060603@ripe.net> On 2014.06.11. 13:16, Antoin Verschuren wrote: > On Wed, 11 Jun 2014, Daniel Karrenberg wrote: > >> Can we put that on the road-map? Anyone else who would like this in the >> UI and API? > > I would sugest to use the probe tags for this. RIPE could give the > anchors a tag that can not be selected through the UI, but > unfortunately, you can create your own tag as well ;-) > Sometimes you would want to measure only with probes that are deployed > at the core of networks, and sometimes you would only want edges, i.e. > probes installed in peoples homes. > The tags could be a nice selection criteria for the type of probes you'd > like to use. > This all depends on the accuracy of the probe owner selecting the tags > though, but some tags like anchor or hasipv6 could be filled automagicaly. Indeed. We intended probe tagging to cover this and more (home probe or not, etc.) Some of this we can and already do do ourselves, some tagging is up for the hosts. The ultimate goal is to make this available as a filter when selecting probes for measurements. Stay tuned! :-) Cheers, Robert From daniel.karrenberg at ripe.net Wed Jun 11 14:49:20 2014 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 11 Jun 2014 14:49:20 +0200 Subject: [atlas] Selecting only anchors for UDM In-Reply-To: References: <53982979.9030606@cesnet.cz> <53982E81.3000803@ripe.net> Message-ID: <53985050.6080605@ripe.net> On 11.06.14 13:16 , Antoin Verschuren wrote: > On Wed, 11 Jun 2014, Daniel Karrenberg wrote: > >> Can we put that on the road-map? Anyone else who would like this in the >> UI and API? > > I would sugest to use the probe tags for this. RIPE could give the > anchors a tag that can not be selected through the UI.... Good suggestion! That is even more general and would work fine for me. If we go down this road I suggest to implement tag selection also wherever it makes sense, such as in the probe list API/UI. Other automatic tags suggested: HASIPV6, HARDWAREVx, IPV6WORKS, ..... Daniel From bortzmeyer at nic.fr Wed Jun 11 14:54:49 2014 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 11 Jun 2014 14:54:49 +0200 Subject: [atlas] Selecting only anchors for UDM In-Reply-To: References: <53982979.9030606@cesnet.cz> <53982E81.3000803@ripe.net> Message-ID: <20140611125449.GA14120@nic.fr> On Wed, Jun 11, 2014 at 01:16:21PM +0200, Antoin Verschuren wrote a message of 18 lines which said: > some tags like anchor or hasipv6 could be filled automagicaly. For "hasipv6", it is more complicated than it seems https://labs.ripe.net/Members/stephane_bortzmeyer/how-many-atlas-probes-believe-they-have-ipv6-but-are-wrong From daniel.karrenberg at ripe.net Wed Jun 11 15:44:48 2014 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 11 Jun 2014 15:44:48 +0200 Subject: [atlas] Selecting only anchors for UDM In-Reply-To: <20140611125449.GA14120@nic.fr> References: <53982979.9030606@cesnet.cz> <53982E81.3000803@ripe.net> <20140611125449.GA14120@nic.fr> Message-ID: <53985D50.9010302@ripe.net> On 11.06.14 14:54 , Stephane Bortzmeyer wrote: > On Wed, Jun 11, 2014 at 01:16:21PM +0200, > Antoin Verschuren wrote > a message of 18 lines which said: > >> some tags like anchor or hasipv6 could be filled automagicaly. > > For "hasipv6", it is more complicated than it seems > Hence IPV6WORKS. ;-) From bortzmeyer at nic.fr Wed Jun 11 15:56:12 2014 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 11 Jun 2014 15:56:12 +0200 Subject: [atlas] Selecting only anchors for UDM In-Reply-To: <53985D50.9010302@ripe.net> References: <53982979.9030606@cesnet.cz> <53982E81.3000803@ripe.net> <20140611125449.GA14120@nic.fr> <53985D50.9010302@ripe.net> Message-ID: <20140611135612.GA21146@nic.fr> On Wed, Jun 11, 2014 at 03:44:48PM +0200, Daniel Karrenberg wrote a message of 11 lines which said: > Hence IPV6WORKS. ;-) Set how? Pinging a few Anchors and checking that at least N % answers? From daniel.karrenberg at ripe.net Wed Jun 11 16:09:02 2014 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 11 Jun 2014 16:09:02 +0200 Subject: [atlas] Selecting only anchors for UDM In-Reply-To: <20140611135612.GA21146@nic.fr> References: <53982979.9030606@cesnet.cz> <53982E81.3000803@ripe.net> <20140611125449.GA14120@nic.fr> <53985D50.9010302@ripe.net> <20140611135612.GA21146@nic.fr> Message-ID: <539862FE.5000107@ripe.net> On 11.06.14 15:56 , Stephane Bortzmeyer wrote: > On Wed, Jun 11, 2014 at 03:44:48PM +0200, > Daniel Karrenberg wrote > a message of 11 lines which said: > >> Hence IPV6WORKS. ;-) > > Set how? Pinging a few Anchors and checking that at least N % answers? That is a very open question and we'd like input about it. My *personal* straw-man for IPV6WORKS would be "At least 3 IPv6 targets pinged successfully in the past 24 hours". IPv6 targets should be high-availability built-in measurement targets such as anchors and root name servers. The number and time interval can be discussed. The problem with this is that one wants to select probes that have a structural local problem while keeping probes that have intermittent and less local problems. In other words: if we exclude too many non-working probes we cannot easily measure real operational problems. Hence I proposed HASIPV6 which could mean that a non-link-local IPv6 address is configured or something similar. The nice thing about tags is that we can have as many we consider useful ... Daniel From klaus.mailinglists at pernau.at Wed Jun 11 17:39:02 2014 From: klaus.mailinglists at pernau.at (Klaus Darilion) Date: Wed, 11 Jun 2014 17:39:02 +0200 Subject: [atlas] Selecting only anchors for UDM In-Reply-To: <53985D50.9010302@ripe.net> References: <53982979.9030606@cesnet.cz> <53982E81.3000803@ripe.net> <20140611125449.GA14120@nic.fr> <53985D50.9010302@ripe.net> Message-ID: <53987816.4050307@pernau.at> Am 11.06.2014 15:44, schrieb Daniel Karrenberg: > On 11.06.14 14:54 , Stephane Bortzmeyer wrote: >> On Wed, Jun 11, 2014 at 01:16:21PM +0200, >> Antoin Verschuren wrote >> a message of 18 lines which said: >> >>> some tags like anchor or hasipv6 could be filled automagicaly. >> For "hasipv6", it is more complicated than it seems >> > Hence IPV6WORKS. ;-) Actually I never would want to make any IPv6 test from a probe which does not have the IPV6WORKS tag. Thus, probes which are known to knot work, should never be selected for measurements. regards Klaus From gert at space.net Wed Jun 11 21:50:04 2014 From: gert at space.net (Gert Doering) Date: Wed, 11 Jun 2014 21:50:04 +0200 Subject: [atlas] Selecting only anchors for UDM In-Reply-To: <539862FE.5000107@ripe.net> References: <53982979.9030606@cesnet.cz> <53982E81.3000803@ripe.net> <20140611125449.GA14120@nic.fr> <53985D50.9010302@ripe.net> <20140611135612.GA21146@nic.fr> <539862FE.5000107@ripe.net> Message-ID: <20140611195004.GJ46558@Space.Net> Hi, On Wed, Jun 11, 2014 at 04:09:02PM +0200, Daniel Karrenberg wrote: > My *personal* straw-man for IPV6WORKS would be "At least 3 IPv6 targets > pinged successfully in the past 24 hours". IPv6 targets should be > high-availability built-in measurement targets such as anchors and root > name servers. The number and time interval can be discussed. "works for me". The Internet being what it is, "can reach all of " will most likely never be true for a given probe, whatever is. OTOH for reachability testing, probes that can *not* reach 100% of but at least "some part of " are a much more interesting candidate for testing - because testing when you already know "100%, good" is a bit boring. So, yes, what Daniel proposed. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From gert at space.net Wed Jun 11 21:51:16 2014 From: gert at space.net (Gert Doering) Date: Wed, 11 Jun 2014 21:51:16 +0200 Subject: [atlas] Selecting only anchors for UDM In-Reply-To: <53987816.4050307@pernau.at> References: <53982979.9030606@cesnet.cz> <53982E81.3000803@ripe.net> <20140611125449.GA14120@nic.fr> <53985D50.9010302@ripe.net> <53987816.4050307@pernau.at> Message-ID: <20140611195116.GK46558@Space.Net> Hi, On Wed, Jun 11, 2014 at 05:39:02PM +0200, Klaus Darilion wrote: > Actually I never would want to make any IPv6 test from a probe which > does not have the IPV6WORKS tag. Thus, probes which are known to knot > work, should never be selected for measurements. Now what is that you want to measure? If I'm out to measure how well IPv6 works in practice, I'm actually more interested in probes that have *some* IPv6 reachability - or maybe even just "have a global IPv6 address" - than probes where I already know that they can reach everybody just fine... 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From robert at ripe.net Wed Jun 11 23:07:51 2014 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 11 Jun 2014 23:07:51 +0200 Subject: [atlas] Selecting only anchors for UDM In-Reply-To: <20140611135612.GA21146@nic.fr> References: <53982979.9030606@cesnet.cz> <53982E81.3000803@ripe.net> <20140611125449.GA14120@nic.fr> <53985D50.9010302@ripe.net> <20140611135612.GA21146@nic.fr> Message-ID: <5398C527.8090507@ripe.net> On 2014.06.11. 15:56, Stephane Bortzmeyer wrote: > On Wed, Jun 11, 2014 at 03:44:48PM +0200, > Daniel Karrenberg wrote > a message of 11 lines which said: > >> Hence IPV6WORKS. ;-) > > Set how? Pinging a few Anchors and checking that at least N % answers? Daniel is exposing some info about stuff that we're actually working on, but we did not announce it yet :-) but yes, the basic idea is that we'll look at how the probe performed in the last period, and if it had enough success, we'll consider it capable of doing ipv4/ipv4/dns/whatever. Then use this knowledge in the measurement scheduler when users want to use those features. That's a departure from "the probe claims that it can do X so we'll go with that" -- which is the main theme behind Stephane's article. We may even have a switch that controls "use probes that think they can do v6 but it doesn't really work" to check the corner cases. If there's a need for such thing. (Is that operationally useful? Or research only?) Cheers, Robert From gert at space.net Wed Jun 11 23:10:22 2014 From: gert at space.net (Gert Doering) Date: Wed, 11 Jun 2014 23:10:22 +0200 Subject: [atlas] Selecting only anchors for UDM In-Reply-To: <5398C527.8090507@ripe.net> References: <53982979.9030606@cesnet.cz> <53982E81.3000803@ripe.net> <20140611125449.GA14120@nic.fr> <53985D50.9010302@ripe.net> <20140611135612.GA21146@nic.fr> <5398C527.8090507@ripe.net> Message-ID: <20140611211022.GA47096@Space.Net> Hi, On Wed, Jun 11, 2014 at 11:07:51PM +0200, Robert Kisteleki wrote: > We may even have a switch that controls "use probes that think they can do > v6 but it doesn't really work" to check the corner cases. If there's a need > for such thing. (Is that operationally useful? Or research only?) Can you see probes that claim to have working IPv4, but haven't? AKA: is your controller infrastructure reachable over IPv6, and will the probes use it? 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From robert at ripe.net Wed Jun 11 23:17:57 2014 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 11 Jun 2014 23:17:57 +0200 Subject: [atlas] Selecting only anchors for UDM In-Reply-To: <20140611211022.GA47096@Space.Net> References: <53982979.9030606@cesnet.cz> <53982E81.3000803@ripe.net> <20140611125449.GA14120@nic.fr> <53985D50.9010302@ripe.net> <20140611135612.GA21146@nic.fr> <5398C527.8090507@ripe.net> <20140611211022.GA47096@Space.Net> Message-ID: <5398C785.6070206@ripe.net> On 2014.06.11. 23:10, Gert Doering wrote: > Hi, > > On Wed, Jun 11, 2014 at 11:07:51PM +0200, Robert Kisteleki wrote: >> We may even have a switch that controls "use probes that think they >> can do v6 but it doesn't really work" to check the corner cases. If >> there's a need for such thing. (Is that operationally useful? Or >> research only?) > > Can you see probes that claim to have working IPv4, but haven't? With enough probes/locations, we can see many kinds of corner cases. I'm sure we have probes in this condition... > AKA: is your controller infrastructure reachable over IPv6, and will > the probes use it? Short version: yes, all of our infrastructure is fully dual stack, without exceptions. The trick that we have to apply is how to reliably know if the probe can actually use IPv6 and/or IPv4. For this, we'll use results of real life measurements. Robert From jared at puck.nether.net Thu Jun 12 00:59:08 2014 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 11 Jun 2014 18:59:08 -0400 Subject: [atlas] Selecting only anchors for UDM In-Reply-To: <53987816.4050307@pernau.at> References: <53982979.9030606@cesnet.cz> <53982E81.3000803@ripe.net> <20140611125449.GA14120@nic.fr> <53985D50.9010302@ripe.net> <53987816.4050307@pernau.at> Message-ID: On Jun 11, 2014, at 11:39 AM, Klaus Darilion wrote: > Am 11.06.2014 15:44, schrieb Daniel Karrenberg: >> On 11.06.14 14:54 , Stephane Bortzmeyer wrote: >>> On Wed, Jun 11, 2014 at 01:16:21PM +0200, >>> Antoin Verschuren wrote >>> a message of 18 lines which said: >>> >>>> some tags like anchor or hasipv6 could be filled automagicaly. >>> For "hasipv6", it is more complicated than it seems >>> >> Hence IPV6WORKS. ;-) > Actually I never would want to make any IPv6 test from a probe which does not have the IPV6WORKS tag. Thus, probes which are known to knot work, should never be selected for measurements. I ?generally? agree with this. ?IPv6-works? is defined as can contact greater than 50% of atlas anchors. (I?m surprised at how little traffic my anchors see). - Jared From BECHA at ripe.net Thu Jun 12 11:30:56 2014 From: BECHA at ripe.net (Vesna Manojlovic) Date: Thu, 12 Jun 2014 11:30:56 +0200 Subject: [atlas] Using RIPE Atlas to Debug Network Issues Message-ID: <53997350.3090105@ripe.net> Dear colleagues, Please find the use-case for RIPE Atlas in debugging network issues, in this RIPE Labs article written by Tim Kleefass from BelWu?, who is hosting a RIPE Atlas anchor. (and who holds the record for the shortest time from purchasing the anchor to it going live!) https://labs.ripe.net/Members/tim_kleefass/how-fast-the-ripe-atlas-anchor-has-paid-off Regards, Vesna From remaker at gmail.com Thu Jun 12 17:32:02 2014 From: remaker at gmail.com (Phillip Remaker) Date: Thu, 12 Jun 2014 08:32:02 -0700 Subject: [atlas] Selecting only anchors for UDM In-Reply-To: References: <53982979.9030606@cesnet.cz> <53982E81.3000803@ripe.net> <20140611125449.GA14120@nic.fr> <53985D50.9010302@ripe.net> <53987816.4050307@pernau.at> Message-ID: I currently have a case open where two of my probes on IPv6 networks have no IPv6 address. I was thinking I might reboot them or force an address probe but can't see an obvious way to do that remotely. Ironically, my one probe that reports IPv6 capability has only a ULA address :-/ On Wed, Jun 11, 2014 at 3:59 PM, Jared Mauch wrote: > > On Jun 11, 2014, at 11:39 AM, Klaus Darilion > wrote: > > > Am 11.06.2014 15:44, schrieb Daniel Karrenberg: > >> On 11.06.14 14:54 , Stephane Bortzmeyer wrote: > >>> On Wed, Jun 11, 2014 at 01:16:21PM +0200, > >>> Antoin Verschuren wrote > >>> a message of 18 lines which said: > >>> > >>>> some tags like anchor or hasipv6 could be filled automagicaly. > >>> For "hasipv6", it is more complicated than it seems > >>> > >> Hence IPV6WORKS. ;-) > > Actually I never would want to make any IPv6 test from a probe which > does not have the IPV6WORKS tag. Thus, probes which are known to knot work, > should never be selected for measurements. > > I ?generally? agree with this. ?IPv6-works? is defined as can contact > greater than 50% of atlas anchors. (I?m surprised at how little traffic my > anchors see). > > - Jared > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From remaker at gmail.com Thu Jun 12 21:20:49 2014 From: remaker at gmail.com (Phillip Remaker) Date: Thu, 12 Jun 2014 12:20:49 -0700 Subject: [atlas] Selecting only anchors for UDM In-Reply-To: References: <53982979.9030606@cesnet.cz> <53982E81.3000803@ripe.net> <20140611125449.GA14120@nic.fr> <53985D50.9010302@ripe.net> <53987816.4050307@pernau.at> Message-ID: (Epilogue: User error - my router stopped handing out IPv6 addresses (curse you, Linksys E4200 v1)) Thanks to Robert K. for rebooting my units. I still need to get to the other site and find out why the IPv6 is failing. On Thu, Jun 12, 2014 at 8:32 AM, Phillip Remaker wrote: > I currently have a case open where two of my probes on IPv6 networks have > no IPv6 address. > > I was thinking I might reboot them or force an address probe but can't see > an obvious way to do that remotely. > > Ironically, my one probe that reports IPv6 capability has only a ULA > address :-/ > > > On Wed, Jun 11, 2014 at 3:59 PM, Jared Mauch > wrote: > >> >> On Jun 11, 2014, at 11:39 AM, Klaus Darilion < >> klaus.mailinglists at pernau.at> wrote: >> >> > Am 11.06.2014 15:44, schrieb Daniel Karrenberg: >> >> On 11.06.14 14:54 , Stephane Bortzmeyer wrote: >> >>> On Wed, Jun 11, 2014 at 01:16:21PM +0200, >> >>> Antoin Verschuren wrote >> >>> a message of 18 lines which said: >> >>> >> >>>> some tags like anchor or hasipv6 could be filled automagicaly. >> >>> For "hasipv6", it is more complicated than it seems >> >>> >> >> Hence IPV6WORKS. ;-) >> > Actually I never would want to make any IPv6 test from a probe which >> does not have the IPV6WORKS tag. Thus, probes which are known to knot work, >> should never be selected for measurements. >> >> I ?generally? agree with this. ?IPv6-works? is defined as can contact >> greater than 50% of atlas anchors. (I?m surprised at how little traffic my >> anchors see). >> >> - Jared >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mgalante at ripe.net Wed Jun 18 14:14:22 2014 From: mgalante at ripe.net (Michela Galante) Date: Wed, 18 Jun 2014 14:14:22 +0200 Subject: [atlas] AFRINIC (MU) has joined RIPE Atlas anchors Message-ID: Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called mu-plu-as327681 and it is hosted by AFRINIC in Port Louis, Mauritius. This is the third anchor hosted by an RIR on behalf of the RIPE NCC. Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind regards, Measurements Community Building Team RIPE NCC mcb at ripe.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2612 bytes Desc: not available URL: From j.a.cordero at gmail.com Thu Jun 19 16:59:13 2014 From: j.a.cordero at gmail.com (Juan Antonio Cordero Fuertes) Date: Thu, 19 Jun 2014 16:59:13 +0200 Subject: [atlas] Paris-traceroute variations Message-ID: Not sure this is the right place to ask this... sorry if it is not. I'm trying to configure Paris-traceroute measurements, and it is not clear for me what is the meaning of the *paris* parameter. In https://atlas.ripe.net/docs/udm/ it is said that it corresponds, for values from 1 to 16, to "the number of variations to be used for a Paris traceroute ". What is this? Does it correspond to the number of initial probes to be used by paris-traceroute? I am unable to figure it out from the RIPE Atlas docs... any indication would be appreciated. Thanks, Juan Antonio Cordero -------------- next part -------------- An HTML attachment was scrubbed... URL: From joachim at tingvold.com Mon Jun 23 23:01:36 2014 From: joachim at tingvold.com (Joachim Tingvold) Date: Mon, 23 Jun 2014 23:01:36 +0200 Subject: [atlas] IPv6 ICMP - denied packets Message-ID: <9E7DF69A-6FC3-4E9F-BFCD-DED94C755F0A@tingvold.com> Hi, I recently installed a probe at home, and now my router spits out loads of 'denied icmpv6'-messages. After going through the logs for the last two days, I have ~1900 entries of denies towards the probe -- all of them more or less like this (with different source); ### Jun 22 2014 22:30:22.863 CEST: %IPV6_ACL-6-ACCESSLOGDP: list ipv6-inbound/2100 denied icmpv6 2A01:4F8:130:24A4::13:76 (Po1.102) -> {PROBE-IPV6-ADDRESS} (1/4), 8 packets ### I've got an ACL applied ingress on the link to my ISP, and the relevant part is shown below; ### ipv6 access-list ipv6-inbound sequence 2000 permit icmp any any echo-reply sequence 2005 permit icmp any any echo-request sequence 2010 permit icmp any any packet-too-big sequence 2015 permit icmp any any time-exceeded sequence 2020 permit icmp any any destination-unreachable sequence 2025 permit icmp any any parameter-problem sequence 2100 deny icmp any any log-input ### This ACL conforms to RFC4890[1] (except the Mobile IPv6 part). Of the 1900 entries, all of them are ICMPv6 type 1. ~300 of them have the code bit[2] set to 1, and ~1600 of them are set to 4. These are the top sources; ### 367 2001:500:2::C 313 2001:500:2D::D 289 2A01:4F8:130:24A4::13:76 289 2001:500:3::42 196 2A01:4F8:121:30A4::78:15 161 2001:DC3::35 100 2001:7FE::53 67 2001:7FD::1 60 2001:500:2F::F ### All of these are DNS root servers (except those starting with 2A01:4F8, which are some Atlas-thingies). It seems to me that the Atlas-probe sends quite some amount of ICMPv6-packets to the root DNS-servers (and even Atlas' own boxes), that are being returned with errors. Why does the probe do this, and does it actually rely on these replies? [1] [2] -- Joachim -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From philip.homburg at ripe.net Mon Jun 23 23:19:53 2014 From: philip.homburg at ripe.net (Philip Homburg) Date: Mon, 23 Jun 2014 23:19:53 +0200 Subject: [atlas] IPv6 ICMP - denied packets In-Reply-To: <9E7DF69A-6FC3-4E9F-BFCD-DED94C755F0A@tingvold.com> References: <9E7DF69A-6FC3-4E9F-BFCD-DED94C755F0A@tingvold.com> Message-ID: <53A899F9.5080101@ripe.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014/06/23 23:01 , Joachim Tingvold wrote: > Hi, > > I recently installed a probe at home, and now my router spits out > loads of 'denied icmpv6'-messages. > > After going through the logs for the last two days, I have ~1900 > entries of denies towards the probe -- all of them more or less > like this (with different source); > > ### Jun 22 2014 22:30:22.863 CEST: %IPV6_ACL-6-ACCESSLOGDP: list > ipv6-inbound/2100 denied icmpv6 2A01:4F8:130:24A4::13:76 (Po1.102) > -> {PROBE-IPV6-ADDRESS} (1/4), 8 packets ### > > I've got an ACL applied ingress on the link to my ISP, and the > relevant part is shown below; > > ### ipv6 access-list ipv6-inbound sequence 2000 permit icmp any any > echo-reply sequence 2005 permit icmp any any echo-request sequence > 2010 permit icmp any any packet-too-big sequence 2015 permit icmp > any any time-exceeded sequence 2020 permit icmp any any > destination-unreachable sequence 2025 permit icmp any any > parameter-problem sequence 2100 deny icmp any any log-input ### > > This ACL conforms to RFC4890[1] (except the Mobile IPv6 part). > > Of the 1900 entries, all of them are ICMPv6 type 1. ~300 of them > have the code bit[2] set to 1, and ~1600 of them are set to 4. Type 1, code 4 is port unreachable. That is triggered by UDP traceroute. It would be better not to filter those packets. Type 1, code 1 means administratively prohibited. It is best to allow that one as well. Or in general, any destination unreachable ICMP. Though I don't understand why 'sequence 2020 permit icmp any any destination-unreachable' does accept those packets. Philip -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlOomfkACgkQ23LKRM64egJu+QCfVdUc8qMYufSw+IvThUYfzPyn nwYAoIK0MmsAYptBL8DUgqCB4bb1brC0 =5Cqj -----END PGP SIGNATURE----- From joachim at tingvold.com Tue Jun 24 00:15:10 2014 From: joachim at tingvold.com (Joachim Tingvold) Date: Tue, 24 Jun 2014 00:15:10 +0200 Subject: [atlas] IPv6 ICMP - denied packets In-Reply-To: <53A899F9.5080101@ripe.net> References: <9E7DF69A-6FC3-4E9F-BFCD-DED94C755F0A@tingvold.com> <53A899F9.5080101@ripe.net> Message-ID: <40D16107-9959-4A05-85C2-DB97F7787E7D@tingvold.com> On 23 Jun 2014, at 23:19, Philip Homburg wrote: > Type 1, code 4 is port unreachable. That is triggered by UDP > traceroute. It would be better not to filter those packets. > > Type 1, code 1 means administratively prohibited. It is best to allow > that one as well. Or in general, any destination unreachable ICMP. > > Though I don't understand why 'sequence 2020 permit icmp any any > destination-unreachable' does accept those packets. Does or doesn't? (-: In any case; i figured out that 'destination-unreachable' actually only means type 1, code 3, which would explain a lot. A bit confusing name I guess (even though it makes sense, kinda). So, I'll just change 'destination-unreachable' (type 1, code 3) to 'unreachable' (type 1, all codes), and it should be good. -- Joachim -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From robert at ripe.net Tue Jun 24 09:21:25 2014 From: robert at ripe.net (Robert Kisteleki) Date: Tue, 24 Jun 2014 09:21:25 +0200 Subject: [atlas] IPv6 ICMP - denied packets In-Reply-To: <9E7DF69A-6FC3-4E9F-BFCD-DED94C755F0A@tingvold.com> References: <9E7DF69A-6FC3-4E9F-BFCD-DED94C755F0A@tingvold.com> Message-ID: <53A926F5.6060104@ripe.net> On 2014.06.23. 23:01, Joachim Tingvold wrote: > It seems to me that the Atlas-probe sends quite some amount of > ICMPv6-packets to the root DNS-servers (and even Atlas' own boxes), > that are being returned with errors. Why does the probe do this, and > does it actually rely on these replies? Besides the technicalities of firewall rules: all probes are automatically involved in measurements towards root DNS servers (ping/trace/DNS) and pieces of the infrastructure (ping/trace). We use this data to establish baselines about the probe's capabilities and to power the maps available on the site. Many probes report problems in one way or another; we are far beyond the point where we can rely on all (or a set of carefully selected) probes to supply useful data. Regards, Robert From philip.homburg at ripe.net Thu Jun 26 13:13:53 2014 From: philip.homburg at ripe.net (Philip Homburg) Date: Thu, 26 Jun 2014 13:13:53 +0200 Subject: [atlas] Paris-traceroute variations In-Reply-To: References: Message-ID: <53AC0071.8000200@ripe.net> Hi Juan, On 2014/06/19 16:59 , Juan Antonio Cordero Fuertes wrote: > Not sure this is the right place to ask this... sorry if it is not. > > I'm trying to configure Paris-traceroute measurements, and it is not > clear for me what is the meaning of the /paris/ parameter. In > https://atlas.ripe.net/docs/udm/ it is said that it corresponds, for > values from 1 to 16, to "the number of variations to be used for a Paris > traceroute ". What is this? Does it > correspond to the number of initial probes to be used by > paris-traceroute? I am unable to figure it out from the RIPE Atlas > docs... any indication would be appreciated. Paris-traceroute tries to make sure that all packets of a traceroute take the same route through a load balancer. This in contrast to traditional traceroute where packets from different hops typically take different routes when load balancers are involved. However, in the case of paris-traceroute it is still interesting to find out if there are multiple routes or not. For this reason, the traceroute measurement creates different variations that may take a different route. Each interval, it will try one variation. So if you select 16 variations then it will take 16 intervals before you get back to the first one. Philip From randy at psg.com Thu Jun 26 22:46:12 2014 From: randy at psg.com (Randy Bush) Date: Fri, 27 Jun 2014 05:46:12 +0900 Subject: [atlas] Paris-traceroute variations In-Reply-To: <53AC0071.8000200@ripe.net> References: <53AC0071.8000200@ripe.net> Message-ID: > Each interval, it will try one variation. So if you select 16 > variations then it will take 16 intervals before you get back to the > first one. i think that, as we showed in [0], 16 may be low for typical paths. randy [0] - https://ripe66.ripe.net/presentations/128-130513.tokyo-ping.pdf From philip.homburg at ripe.net Fri Jun 27 12:17:58 2014 From: philip.homburg at ripe.net (Philip Homburg) Date: Fri, 27 Jun 2014 12:17:58 +0200 Subject: [atlas] Paris-traceroute variations In-Reply-To: References: <53AC0071.8000200@ripe.net> Message-ID: <53AD44D6.7040203@ripe.net> On 2014/06/26 22:46 , Randy Bush wrote: >> Each interval, it will try one variation. So if you select 16 >> variations then it will take 16 intervals before you get back to the >> first one. > > i think that, as we showed in [0], 16 may be low for typical paths. > [0] - https://ripe66.ripe.net/presentations/128-130513.tokyo-ping.pdf Hi Randy, In that presentation I cannot find any clear evidence that that there are more than 16 unique paths. But maybe I missed something. In any case, we can easily increase that value. So far we didn't get any complaints that 16 was too low, but if somebody wants to experiment with more than 16 then just ask. Philip From randy at psg.com Fri Jun 27 22:31:39 2014 From: randy at psg.com (Randy Bush) Date: Sat, 28 Jun 2014 05:31:39 +0900 Subject: [atlas] Paris-traceroute variations In-Reply-To: <53AD44D6.7040203@ripe.net> References: <53AC0071.8000200@ripe.net> <53AD44D6.7040203@ripe.net> Message-ID: >>> Each interval, it will try one variation. So if you select 16 >>> variations then it will take 16 intervals before you get back to the >>> first one. >> i think that, as we showed in [0], 16 may be low for typical paths. >> [0] - https://ripe66.ripe.net/presentations/128-130513.tokyo-ping.pdf > In that presentation I cannot find any clear evidence that that there > are more than 16 unique paths. But maybe I missed something. apologies. i guess it was in the paper not the preso, uppr right of page 3 of C. Pelsser, L. Cittadini, S. Vissicchio, and R. Bush, From Paris to Tokyo: On the Suitability of Ping to Measure Latency, 2013 Internet Measurement Conference. the intuition is that it is a function of the richness of the path diversity. perhaps a tunable? randy From emile.aben at ripe.net Sat Jun 28 11:46:15 2014 From: emile.aben at ripe.net (Emile Aben) Date: Sat, 28 Jun 2014 11:46:15 +0200 Subject: [atlas] Paris-traceroute variations In-Reply-To: References: <53AC0071.8000200@ripe.net> <53AD44D6.7040203@ripe.net> Message-ID: <53AE8EE7.7010502@ripe.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 27/06/14 22:31, Randy Bush wrote: >>>> Each interval, it will try one variation. So if you select >>>> 16 variations then it will take 16 intervals before you get >>>> back to the first one. >>> i think that, as we showed in [0], 16 may be low for typical >>> paths. [0] - >>> https://ripe66.ripe.net/presentations/128-130513.tokyo-ping.pdf >> >>> In that presentation I cannot find any clear evidence that that there >> are more than 16 unique paths. But maybe I missed something. > > apologies. i guess it was in the paper not the preso, uppr right > of page 3 of > > C. Pelsser, L. Cittadini, S. Vissicchio, and R. Bush, From Paris > to Tokyo: On the Suitability of Ping to Measure Latency, 2013 > Internet Measurement Conference. > > > the intuition is that it is a function of the richness of the > path diversity. > > perhaps a tunable? and/or a mode where flow-id is picked randomly until it finds no more additional paths? I guess the only parameter needed for that is defining for how long to try finding new IP addresses in a traceroute before giving up, ie. I'll probe for 10 more rounds after I find a new IP address in a traceroute before giving up. I think it is similar to: http://www-rp.lip6.fr/~augustin/augustin07multipath.pdf cheers, Emile -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlOujucACgkQj05ACITZaqqT0QEAjHR8MgAzMibxmPVaX/Uw73mK p1Ug8g0Sodzu5zh128MA/1V1KVq4cnVpOMEXfgbrrdwNXGZ9FeA4xt/rLwrH6BXs =XImt -----END PGP SIGNATURE----- From daniel.karrenberg at ripe.net Sat Jun 28 12:17:36 2014 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Sat, 28 Jun 2014 12:17:36 +0200 Subject: [atlas] Paris-traceroute variations In-Reply-To: <53AE8EE7.7010502@ripe.net> References: <53AC0071.8000200@ripe.net> <53AD44D6.7040203@ripe.net> <53AE8EE7.7010502@ripe.net> Message-ID: <115FC3D6-E0A6-4205-BA89-51C1BFA7675A@ripe.net> i suggest that the documentation of any variation or parameter includes a good description of its impact on measurement elapsed time and resources/credits. ---------- Sent from a hand held device. From philip.homburg at ripe.net Mon Jun 30 12:11:31 2014 From: philip.homburg at ripe.net (Philip Homburg) Date: Mon, 30 Jun 2014 12:11:31 +0200 Subject: [atlas] Paris-traceroute variations In-Reply-To: References: <53AC0071.8000200@ripe.net> <53AD44D6.7040203@ripe.net> Message-ID: <53B137D3.1090807@ripe.net> On 2014/06/27 22:31 , Randy Bush wrote: > apologies. i guess it was in the paper not the preso, uppr right of > page 3 of > > C. Pelsser, L. Cittadini, S. Vissicchio, and R. Bush, From Paris to > Tokyo: On the Suitability of Ping to Measure Latency, 2013 Internet > Measurement Conference. > > > the intuition is that it is a function of the richness of the path > diversity. > > perhaps a tunable? The way it looks to me is that that section argues that you need more than 6 and that 32 is enough. It doesn't really say that 16 is not enough :-) But I just created an internal ticket to have the limit raised to 64. That should be ample for anybody who wants to experiment. Philip From randy at psg.com Mon Jun 30 12:19:05 2014 From: randy at psg.com (Randy Bush) Date: Mon, 30 Jun 2014 19:19:05 +0900 Subject: [atlas] Paris-traceroute variations In-Reply-To: <53B137D3.1090807@ripe.net> References: <53AC0071.8000200@ripe.net> <53AD44D6.7040203@ripe.net> <53B137D3.1090807@ripe.net> Message-ID: >> apologies. i guess it was in the paper not the preso, uppr right of >> page 3 of >> C. Pelsser, L. Cittadini, S. Vissicchio, and R. Bush, From Paris to >> Tokyo: On the Suitability of Ping to Measure Latency, 2013 Internet >> Measurement Conference. >> >> the intuition is that it is a function of the richness of the path >> diversity. >> perhaps a tunable? > The way it looks to me is that that section argues that you need more > than 6 and that 32 is enough. It doesn't really say that 16 is not > enough :-) it's been a while, and something happened to my memory but i forget what. but i suspect it is dependent on the diversity of the particular path. > But I just created an internal ticket to have the limit raised to 64. > That should be ample for anybody who wants to experiment. cool! randy