Subject: [MMUSIC] prefer IPv6 for ICE dual stack fairness

From: 🔓Dan Wing <[email-masked]>
Date: Wed, 20 May 2015 11:25:42 -0700

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

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Thu, 21 May 2015 12:37:48 +0000

Hi,

> On 20 May 2015, at 20:25, Dan Wing (dwing) <[email-masked]> wrote:
> 
> 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.  
Thanks for pointing this out and providing text.

> 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.  
Specific formulas and recommendations is removed from the draft. After “excessive” threats that any formula would be nitpicked to death, because getting such a formula wrong in a RFC would potentially cause some harm. The way the draft is structured now give hint on how to achieve fairness in a way that would not break interop with existing implementations.

Section 4 do mention RFC 6555, adding some text suggesting the timing proposed there is excessive for ICE usage is probably a good idea. 

> 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.
> 
What is described in this draft should happen before any connectivity check are sent. I think data like RTT and retransmits would be valuable for ICE when choosing the active candidate pair. If we manage to go away from alway using the highest priority pair. 

>    one or a few round trips of (small) ICE packets.  
Agree. But in this draft we have not even sent any packets. We are just trying to figure out a “upfront and fair” distribution of the coming packets. 
Would adding the above text imply that there is a larger problem needed to be solved? If so should we point out that this draft only solves the upfront fairness packet distribution?

> Recent analysis
>    IPv4 as was suggested by Happy Eyeballs [RFC6555].  
This is spot on. With current implementations this would ensure IPv6 candidates winning due to a higher priority candidate pair.

> In the future,
>    [I-D.tuexen-tsvwg-sctp-multipath]).”
Yes. ICE can help those actually do that by providing the above protocol like mprtp with the valid list and initial RTT and retrans values. 

To get a complete valid list the order of how you do checks does not matter, you need to run through them all. But for finding a candidate pair to send media on immediately the order of the checks do play a role. Once a candidate pair is chosen, the rest of the checks can be completed while media is happily flowing on the selected pair. 

> [Facebook] http://www.computerworld.com/article/2909628/the-future-is-here-you-may-already-be-using-ipv6.html
Can we point to sources like that in an RFC?

.-.
Pål-Erik

> -d
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: 🔓Dan Wing <[email-masked]>
Date: Thu, 21 May 2015 09:54:11 -0700

> Would adding the above text imply that there is a larger problem needed to be solved? If so should we point out that this draft only solves the upfront fairness packet distribution?

Yes, probably want to say something like:

  "The quality of each candidate-pair path can be determined during ICE connectivity checks (round-trip time, packet loss, jitter) and provide further information regarding path quality.  However, those connectivity metrics do not always correlate to bandwidth or long-term path quality.  So, while this document describes how to fairly order the candidates, the best path can be determined only by using that path."

> Can we point to sources like that in an RFC?

We can point to stable references in an RFC.  I would say computerworld.com is not a stable reference.

-d

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 22 May 2015 07:03:52 +0000

>   "The quality of each candidate-pair path can be determined during ICE
> connectivity checks (round-trip time, packet loss, jitter) and provide further
> information regarding path quality.  However, those connectivity metrics do
> not always correlate to bandwidth or long-term path quality.  So, while this
> document describes how to fairly order the candidates, the best path can be
> determined only by using that path."
> 

WFM. We can site the above the text in the document.

-Tiru