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 <http://www.paris-traceroute.net/>". 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
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 <http://www.paris-traceroute.net/>". 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
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
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
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. <http://conferences.sigcomm.org/imc/2013/papers/imc125s-pelsserA.pdf> the intuition is that it is a function of the richness of the path diversity. perhaps a tunable? randy
-----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. <http://conferences.sigcomm.org/imc/2013/papers/imc125s-pelsserA.pdf>
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-----
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.
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. <http://conferences.sigcomm.org/imc/2013/papers/imc125s-pelsserA.pdf>
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
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. <http://conferences.sigcomm.org/imc/2013/papers/imc125s-pelsserA.pdf> 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
participants (5)
-
Daniel Karrenberg -
Emile Aben -
Juan Antonio Cordero Fuertes -
Philip Homburg -
Randy Bush