[MMUSIC] prefer IPv6 for ICE dual stack fairness

[🔓Dan Wing <[e-mail]>]

Draft-ietf-mmusic-ice-dualstack-fairness needs to encourage a preference for IPv6, rather than a fair race of IPv6/IPv4.  There are lots of reasons for that (mostly to help network operators), but recent Facebook research shows preferring IPv6 helps the end user (see link below).  I wrote some suggested text, which might fit alright into the introduction or a Rationale section.  Some specific recommendation for algorithmic tweaking in the normative section of the document would be needed, but I don't want to erect that straw-man until folks agree there is value in preferring IPv6.  RFC6555 ("Happy Eyeballs") recommended giving IPv6 a 150ms-250ms preference, but that may well be excessive for ICE.  We should consider if re-transmits (which can be detected with draft-ietf-tram-stun-path-data) should have an impact on the algorithm or if it is premature to write that into a standard.


Suggested text:

    "Although the initial connection time over an IP address family
    might often correlate to the faster performing network, the actual
    throughput, latency, and jitter is difficult to discern with only
    one or a few round trips of (small) ICE packets.  Recent analysis
    indicates IPv6 throughput is often faster than IPv4 [Facebook], so
    implementations might want to give IPv6 a slight preference over
    IPv4 as was suggested by Happy Eyeballs [RFC6555].  In the future,
    other standards may actively probe IPv4/IPv6 paths or send traffic
    on multiple paths (e.g., [I-D.ietf-avtcore-mprtp],
    [I-D.tuexen-tsvwg-sctp-multipath])."

[Facebook] http://www.computerworld.com/article/2909628/the-future-is-here-you-may-already-be-using-ipv6.html

-d