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

"Pal Martinsen (palmarti)" <> Thu, 21 May 2015 12:37 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B5BD31AD333 for <>; Thu, 21 May 2015 05:37:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YHB4_h1Xsi28 for <>; Thu, 21 May 2015 05:37:50 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 84B0C1AD2C4 for <>; Thu, 21 May 2015 05:37:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=5248; q=dns/txt; s=iport; t=1432211870; x=1433421470; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=MvZYD4KJ9DOnMhtXog+zMSDnQKcjny8a6VYWHD4AUsU=; b=A9IvTf88ABWWtTG4l3Ox9euk3xX8ixHeqKvDDd0VHm/h+LVe3IIjjtQK XsJ8QmqM1r9ej8g14mp7kEPlk0EF7q3RNvIIVD6d5M7yskSFD5nqIqqWG oAQaBz0imkcQD7aAtV7LmTKIW/3Dq7oYIWDtr/jGhVK9KohEMou69Oxyc c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.13,468,1427760000"; d="scan'208";a="421529660"
Received: from ([]) by with ESMTP; 21 May 2015 12:37:49 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t4LCbnMG003951 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <>; Thu, 21 May 2015 12:37:49 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Thu, 21 May 2015 07:37:49 -0500
From: "Pal Martinsen (palmarti)" <>
To: "Dan Wing (dwing)" <>
Thread-Topic: [MMUSIC] prefer IPv6 for ICE dual stack fairness
Thread-Index: AQHQkypsYLBKK9dU3kqKVlgGrp2t/Z2Gm2GA
Date: Thu, 21 May 2015 12:37:48 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>
Subject: Re: [MMUSIC] prefer IPv6 for ICE dual stack fairness
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 21 May 2015 12:37:53 -0000


> On 20 May 2015, at 20:25, Dan Wing (dwing) <> 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. 

> 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.  
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
>    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].  
This is spot on. With current implementations this would ensure IPv6 candidates winning due to a higher priority candidate pair.

> 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]).”
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]
Can we point to sources like that in an RFC?


> -d
> _______________________________________________
> mmusic mailing list