Hi all, I would like to start some Paris-traceroute measurements from RIPE Atlas probes, with a specific frequency and a control over the paris id. In particular, I am wondering if it is possible to start a traceroute measurement with all the 16 paris id at the same time. Because so far, I only find out how to start periodically a traceroute with a different paris id. I am also a little bit confused about the interval between two measurements. In the doc, it is written that the default value (900s) is the minimum, but when I create a UDM, the minimum interval seems to be 60s. I also tried 10 secondes with Restful API and the measurement started, but the real interval seems to be far upper than 10s. Can you give me more informations about this interval ? Thank you for your help, Thomas.
look at the upside,
In particular, I am wondering if it is possible to start a traceroute measurement with all the 16 paris id at the same time. Because so far, I only find out how to start periodically a traceroute with a different paris id.
if your measurement per id is nicely separated in time, it is a real opportunity to publish in http://www.jir.com/ randy
Hi, It used to be true that the default measurement frequency was also the minimum. We've changed that to allow more frequent measurements, but apparently not all the documentation reflects that. We'll update the documentation. While technically it would be possible to add some feature to the system to do multiple paris variations at (or close to) the same time, this would add a lot of complications to the code base and to result parsing (which is already not simple). Instead, it is already possible to schedule multiple measurements to run at roughly the same time, which provides an approximation to what you describe here. Regards, Robert On 2014.07.17. 4:29, Thomas Holterbach wrote:
Hi all,
I would like to start some Paris-traceroute measurements from RIPE Atlas probes, with a specific frequency and a control over the paris id.
In particular, I am wondering if it is possible to start a traceroute measurement with all the 16 paris id at the same time. Because so far, I only find out how to start periodically a traceroute with a different paris id.
I am also a little bit confused about the interval between two measurements. In the doc, it is written that the default value (900s) is the minimum, but when I create a UDM, the minimum interval seems to be 60s. I also tried 10 secondes with Restful API and the measurement started, but the real interval seems to be far upper than 10s. Can you give me more informations about this interval ?
Thank you for your help,
Thomas.
While technically it would be possible to add some feature to the system to do multiple paris variations at (or close to) the same time, this would add a lot of complications to the code base and to result parsing (which is already not simple). Instead, it is already possible to schedule multiple measurements to run at roughly the same time, which provides an approximation to what you describe here.
how close an approximation? chasing ecmp and lag is bad enough without other changes. folk need reproducible results. randy
On 2014/07/17 11:28 , Randy Bush wrote:
While technically it would be possible to add some feature to the system to do multiple paris variations at (or close to) the same time, this would add a lot of complications to the code base and to result parsing (which is already not simple). Instead, it is already possible to schedule multiple measurements to run at roughly the same time, which provides an approximation to what you describe here.
how close an approximation? chasing ecmp and lag is bad enough without other changes. folk need reproducible results.
As far as I know, the actual hashing algorithms used by load balancers are in general not known. So the only thing paris-traceroute can do is to try to provide consistent results for each variation and try to create enough difference between variations that it likely that all paths are tried. In this context, it doesn't really matter if you try different variations in one measurement or run different measurements. In both cases some bits will be different. But it not possible to predict in advance what is going to happen. Worth pointing out in this context (and it is also documented somewhere) is that if a probe reboots, the bits it uses for paris-traceroute are likely to be different. So consistent results with a single measurement are only achieved for as long as a probe doesn't reboot. Philip
how close an approximation? chasing ecmp and lag is bad enough without other changes. folk need reproducible results.
As far as I know, the actual hashing algorithms used by load balancers are in general not known.
So the only thing paris-traceroute can do is to try to provide consistent results for each variation and try to create enough difference between variations that it likely that all paths are tried.
In this context, it doesn't really matter if you try different variations in one measurement or run different measurements. In both cases some bits will be different. But it not possible to predict in advance what is going to happen.
Worth pointing out in this context (and it is also documented somewhere) is that if a probe reboots, the bits it uses for paris-traceroute are likely to be different. So consistent results with a single measurement are only achieved for as long as a probe doesn't reboot.
a multi-id measurement needs to be closely clusetered in time or changes in routing or other network events can create ugly and unreproducible (in the someone else tries the same experiment) results. don't know about others, but i don't really care about load balancers. it's ecmp and lag on big pipes. randy
On Jul 17, 2014, at 6:49 PM, Randy Bush <randy@psg.com> wrote:
how close an approximation? chasing ecmp and lag is bad enough without other changes. folk need reproducible results.
As far as I know, the actual hashing algorithms used by load balancers are in general not known.
So the only thing paris-traceroute can do is to try to provide consistent results for each variation and try to create enough difference between variations that it likely that all paths are tried.
In this context, it doesn't really matter if you try different variations in one measurement or run different measurements. In both cases some bits will be different. But it not possible to predict in advance what is going to happen.
Worth pointing out in this context (and it is also documented somewhere) is that if a probe reboots, the bits it uses for paris-traceroute are likely to be different. So consistent results with a single measurement are only achieved for as long as a probe doesn't reboot.
a multi-id measurement needs to be closely clusetered in time or changes in routing or other network events can create ugly and unreproducible (in the someone else tries the same experiment) results.
don't know about others, but i don't really care about load balancers. it's ecmp and lag on big pipes.
With ecmp and lag, I hope that a routeur's hash stays consistent as long as the number of interfaces stays constant. The fact that a probe reboot may lead to a change in flow id is an issue. Cristel
participants (5)
-
Pelsser Cristel -
Philip Homburg -
Randy Bush -
Robert Kisteleki -
Thomas Holterbach