> On 10 Nov 2015, at 11:18, Stephan Wolf <s.w...@wolfsec.ch> wrote: >
> Sure, PROBES as an VM in e.g. overloaded environments are a problem. So > Probes on a VM = can result in some troubles in the existing Atlas model. > To > make a "second class" probes I agree that this takes too much efforts. > > ANCHOR as an VM would really make sense. What do you think about this ? I think it simply shifts the problem from source to destination. The destination must also not be overloaded when responding to packets. Someone provisioning a UDM, may have no clue how overloaded the underlying hardware supporting the anchor VM was at the time of the measurement. In a recent IEPG presentation [1], Emile showed us how latencies over IPv4 and IPv6 compare using anchoring measurements. In the methodology, it was clearly stated how the measurements were performed using the 'same' source hardware (probes) and 'same' destination hardware (anchors). This adds confidence to the accuracy of the results. I suspect perhaps we risk losing these RIPE Atlas benefits with the VM approach. PS: Anchors can also be used as probes. [1] http://www.iepg.org/2015-11-01-ietf94/2015-10.iepg-v4v6.emileaben.pdf Best, Vaibhav ===================================================== Vaibhav Bajpai Room 91, Research I School of Engineering and Sciences Jacobs University Bremen, Germany www.vaibhavbajpai.com =====================================================
signature.asc
Description: Message signed with OpenPGP using GPGMail
