[atlas] Flow-id of built-in traceroute measurement
- Previous message (by thread): [atlas] Flow-id of built-in traceroute measurement
- Next message (by thread): [atlas] Scheduling a test for all probes?
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Wenqin SHAO
wenqin.shao at telecom-paristech.fr
Fri Apr 8 11:18:37 CEST 2016
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 -------------- next part -------------- A non-text attachment was scrubbed... Name: ip_diver_cdf.pdf Type: application/pdf Size: 5149 bytes Desc: not available URL: <https://lists.ripe.net/ripe/mail/archives/ripe-atlas/attachments/20160408/b89294df/attachment.pdf> -------------- next part -------------- > On 06 Apr 2016, at 10:36, Philip Homburg <philip.homburg at 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 >
- Previous message (by thread): [atlas] Flow-id of built-in traceroute measurement
- Next message (by thread): [atlas] Scheduling a test for all probes?
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]