perfSONAR User Q&A and Other Discussion

[Tim Chown <>]

Hi,

On 5 May 2016, at 19:51, Brian Candler <> wrote:

On 05/05/2016 18:33, Andrew Lake wrote:

If you do not specify those options, then the underlying tool is going to always prefer IPv6 if both endpoints in the test have v6 addresses, otherwise it will fall back to IPv4. MaDDash in that case will just ask for any result, not caring if its v4 or v6, and display/alert on whatever it gets back. It sounds like this behavior is what you are running into, so creating a couple of tests with ipv4_only and ipv6_only should get the desired result.

OK: creating two meshes with ipv4_only and ipv6_only should do it, I'll give that a go. Thank you.

I agree this is good advice.  It’s also interesting of course to directly compare v4 and v6 performance.

Eli Dart wrote:

> In general, if there is an A record and a AAAA record for the same name, host stacks prefer IPv6.

>

> My understanding is that this is intended to facilitate the transition from IPv4 to IPv6.

>

> This is host-level behaviour.

In summary, yes :)

It boils down to how, e.g., a getaddrinfo() lookup returns an ordered list of v4 and v6 addresses, and how applications then obtain an address to use.

For more info on this see RFC 6724, which describes both source and destination address selection heuristics, which some OSes let you influence, e.g. through /etc/gai.conf on Linux. Not all OSes implement the RFC fully, e.g. OS X has a variant of it, but most now do. It’s an important capability when both a source and a destination may have multiple addresses, and you need a heuristic to pick the best pair.

Further, RFC 6555, “Happy Eyeballs”, describes how applications can attempt v4 and v6 connections in parallel to the same destination host; the first one completing is then used. IPv6 typically gets a few 100ms head start, to favour it. This approach was introduced in earlier days of v6 deployment to avoid noticeable (20-30 second) timeouts if v6 was tried before v4 and v6 was not working; this isn’t really an issue today, but was very useful for the World IPv6 Day back in June 2011 (indeed Google were clever here - they made Google services available by v4 and v6 for the day, and added Happy Eyeballs to Chrome in advance, so they could say ‘for the best experience accessing Google or any other v6-enabled services on IPv6 Day, use Chrome :)). The cost to the provider is more incoming connections, the benefit to the user is no noticeable latency if v6 (or v4) is down.

 

Having said that, I don’t think Happy Eyeballs is appropriate for perfSONAR meshes, as you’d want predictable tests to be run each time, using the ipv4_only or ipv6_only options as suggested above, but it’s useful to bear in mind that many applications now use Happy Eyeballs, including most (all?) common web browsers. 

Best wishes,

Tim

This may be true in general; however it's not true of manually-configured tests in perfsonar, where you can select to use ipv4, ipv6, or both:

<mopooafdddkkneph.png>

Hence it was surprising (to me) that maddash behaved differently.

For tests which I've manually configured in the GUI with both IPv4 and IPv6 checked, they appear like this in regular_testing.conf:

<test>
    <parameters>
        packet_length   180
        test_ipv4_ipv6   1
        type   powstream
    </parameters>
    target   xxx.example.com
    description   POP to POP
    <schedule>
        type   streaming
    </schedule>
</test>

which indeed is documented here:
http://docs.perfsonar.net/config_regular_testing.html#test-ipv4-ipv6-directive

Whereas maddash is different, and instead has "ipv4_only" and "ipv6_only" options:
http://docs.perfsonar.net/config_mesh.html#ipv4-only-directive

I didn't find documented what happens if you omit both.

Regards,

Brian.