Flow-id of built-in traceroute measurement
Dear list, I have some questions concerning the flow-id of built-in traceroute measurements and are seeking for your help. As many of you may have already noticed, the flow-id of the built-in traceroute measurement periodically varies form 0 to 15, in a circular manner. With this behaviour, it is supposed to reveal the diversity of underlying IP paths. In the case that there are more than 16 unique IP paths between a source and destination pair, could this scheme reveal all of these IP paths? If it can, which leads to more than one IP paths per flow-id? Is it normal, from a load balancer point of view? If it can not, then why not a wider range of flow-id (more nuances in header hash results), say [0, 63]? Is it related to common realisation of load balancer? Many thanks in advance. Best regards, Wenqin ==== Wenqin SHAO PhD Candidate Telecom ParisTech
Hi, On 2016/04/05 20:53 , Wenqin SHAO wrote:
I have some questions concerning the flow-id of built-in traceroute measurements and are seeking for your help.
As many of you may have already noticed, the flow-id of the built-in traceroute measurement periodically varies form 0 to 15, in a circular manner. With this behaviour, it is supposed to reveal the diversity of underlying IP paths.
In the case that there are more than 16 unique IP paths between a source and destination pair, could this scheme reveal all of these IP paths? If it can, which leads to more than one IP paths per flow-id? Is it normal, from a load balancer point of view? If it can not, then why not a wider range of flow-id (more nuances in header hash results), say [0, 63]? Is it related to common realisation of load balancer?
Basically, the wider the range, the longer you have to wait for two traceroute results that take the same path. Of course, if you want to investigate one particular path, you can just schedule your own measurement with different parameters. I have not seen any analysis that estimates what percentage of source, destinations pairs would have more than 16 different paths. If that percentage is significant, then it's worth considering raising the value. Philip
Hi Philip, Thank you for replying. I have some observations, but not really statistics, as they only tell the story of my fairly limited sample set. I selected built-in traceroute measurement to b-root from 128 probes hosted in European DC. 123 of them have no more than 16 different IP paths over a weeks' time, i.e. 336 traceroute measurements in all. 3 of them have more than 50 different IP paths, among which 1 have more than 200. Regards, wenqin
On 06 Apr 2016, at 10:36, Philip Homburg <philip.homburg@ripe.net> wrote:
Hi,
On 2016/04/05 20:53 , Wenqin SHAO wrote:
I have some questions concerning the flow-id of built-in traceroute measurements and are seeking for your help.
As many of you may have already noticed, the flow-id of the built-in traceroute measurement periodically varies form 0 to 15, in a circular manner. With this behaviour, it is supposed to reveal the diversity of underlying IP paths.
In the case that there are more than 16 unique IP paths between a source and destination pair, could this scheme reveal all of these IP paths? If it can, which leads to more than one IP paths per flow-id? Is it normal, from a load balancer point of view? If it can not, then why not a wider range of flow-id (more nuances in header hash results), say [0, 63]? Is it related to common realisation of load balancer?
Basically, the wider the range, the longer you have to wait for two traceroute results that take the same path.
Of course, if you want to investigate one particular path, you can just schedule your own measurement with different parameters.
I have not seen any analysis that estimates what percentage of source, destinations pairs would have more than 16 different paths. If that percentage is significant, then it's worth considering raising the value.
Philip
participants (2)
-
Philip Homburg
-
Wenqin SHAO