Re: [MMUSIC] New Version Notification for draft-reddy-mmusic-ice-happy-eyeballs-04.txt

"Pal Martinsen (palmarti)" <palmarti@cisco.com> Fri, 31 January 2014 13:44 UTC

Return-Path: <palmarti@cisco.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9471A0193 for <mmusic@ietfa.amsl.com>; Fri, 31 Jan 2014 05:44:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.736
X-Spam-Level:
X-Spam-Status: No, score=-14.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ekZo0O7HrZha for <mmusic@ietfa.amsl.com>; Fri, 31 Jan 2014 05:44:41 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id F2B971A011B for <mmusic@ietf.org>; Fri, 31 Jan 2014 05:44:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5497; q=dns/txt; s=iport; t=1391175877; x=1392385477; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=BFotr30lzC0RktPW4WrY+cg2YtY/PE/nmKVatlXfmDI=; b=SgqyP2Idte4K/BsS81v0p96NP8KksjIe4C+nJxSpKjRl8YN/LGqrxqdK ntLI/BPOpLKmr4yy3mUT8s7AhzS+twfjSTUfqvFv5F5XFwWDYjtdlqKkP LAj/grqAxNNQWoARqqSpOOBoC97k/f8ivRF0CRC/a4WOg6dyZWav4YM/9 o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgYFAGao61KtJXHB/2dsb2JhbABZgww4V704gQYWdIIlAQEBAwEnUAIFCwIBCBguMiUCBA4FG4diCA3MLRMEjk8zB4MkgRQBA5gqkiGBb4E+gio
X-IronPort-AV: E=Sophos;i="4.95,758,1384300800"; d="scan'208";a="300985984"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 31 Jan 2014 13:44:37 +0000
Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s0VDiboV024716 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 31 Jan 2014 13:44:37 GMT
Received: from xmb-rcd-x06.cisco.com ([169.254.6.190]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Fri, 31 Jan 2014 07:44:36 -0600
From: "Pal Martinsen (palmarti)" <palmarti@cisco.com>
To: Ari Keränen <ari.keranen@ericsson.com>
Thread-Topic: [MMUSIC] New Version Notification for draft-reddy-mmusic-ice-happy-eyeballs-04.txt
Thread-Index: AQHPEFUUlb4N8W3Wl06M5kiJnPk5wZqUXPIAgAZGcwCAAv8DgIABtqYA
Date: Fri, 31 Jan 2014 13:44:36 +0000
Message-ID: <37A6AA83-867F-4DD1-A79D-081ECFA23B22@cisco.com>
References: <20131209121243.31704.62698.idtracker@ietfa.amsl.com> <540B748E-8B51-4763-B75F-F80ACCFB53D7@cisco.com> <52D01911.8030804@ericsson.com> <647464EE-B8E0-47FA-A375-8C758046D854@cisco.com> <B6CF90AA-44E7-4D38-81CA-8A85370944A7@ericsson.com> <7C0E6D63-D816-4415-B621-73A0309C6AB2@cisco.com> <52EA38C9.4070003@ericsson.com>
In-Reply-To: <52EA38C9.4070003@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.55.154.69]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <B9CEC26406FAA74CA264278F763D899F@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: mmusic <mmusic@ietf.org>, "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com>
Subject: Re: [MMUSIC] New Version Notification for draft-reddy-mmusic-ice-happy-eyeballs-04.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 Jan 2014 13:44:43 -0000

On 30 Jan 2014, at 12:34 pm, Ari Keränen <ari.keranen@ericsson.com> wrote:

> Hi,
> 
> On 28/01/14 15:49, Pal Martinsen (palmarti) wrote:
>> Just posted -05 version of the draft.
> 
> Thanks! Here's a few comments on the latest version.
> 
> The abstract says:
> 
>>   This document provides guidelines on how to make ICE [RFC5245]
>>   conclude faster in IPv4/IPv6 dual-stack scenarios where broken paths
>>   exist.  This will lead to more sustained IPv6 deployment as users
>>   will no longer have an incentive to disable IPv6.
> 
> Out of (much of) context, especially the second sentence seems like a quite strong statement. I guess there could be other reasons than this for disabling v6, for example.

Agree. Sentence removed.

> 
> And nit: usually abstract should not contain references and open the ICE acronym.
> 
Fixed.


>>   An ICE agent can choose an algorithm or a technique of its choice to
>>   ensure that the resulting check lists have a fair intermingled mix of
>>   IPv4 and IPv6 address families.  Modifying the check list directly
>>   can lead to uncoordinated local and remote check lists that result in
>>   ICE taking longer to complete.
> 
> Not only can the tests take longer, but they can potentially also fail if the lists get badly out of sync since once you have made a NAT binding with a connectivity check packet, the check to other direction must come before the binding expires. But I suppose this will not be a problem with the proposed solution since the lists will be in sync?
> 
Added failure as well to further scare the reader. :-)

And yes, the list must be kept in sync.

>>   The local and remote agent can have different algorithms for choosing
>>   the type preference value without any impact on coordination between
>>   the local and remote check list.
> 
> What do you mean by "without any impact on coordination”?

kept in sync?

New text:

The local and remote agent can have different algorithms for choosing
the local preference value without impacting the synchronisation
between the local and remote check list.
> 

>>   Where G is the candidate provided by the controlling agent and D the
> 
> s/candidate/priority of the candidate/
> 
tnx


>> Do we ask for WG adoption, or do we need another MMUSIC session discussing this?
> 
> Given this new approach, I think it's too early to ask for WG adoption. Rather we need more discussion especially here on the list and possibly at the meeting.
> 
Ok. 

Just a bit afraid of wasting cycles if this proves to not so useful. 

> What I would find helpful for discussion is that if you could provide a step-by-step example of how the candidate lists are formed and connectivity checks done in cases where a) both support this with same promo algo b) both support this but with different promo algo c) only one endpoint supports this.
> 

As I do believe in running code, I wrote a simple implementation of the algorithm described below.

It can be downloaded from:
https://github.com/palerikm/HappyE-ICE-Test

>From README:

Compiling
===============
Run ./bootstrap to create the configure script.

then do ./configure
and
 
make

Running
===============

There are two txt files with candidates. One with local candidates where priorities needs to be calculated and a predefined remote candidate file. (Please Note parsing is crude so keep the files clean..)

the program can be run as follows:

src/icehetest 4 candidates.txt remoteCandidates.txt 

4 indicates the number of concecutive candidates if same address type allowed.


> Also maybe a recommended promo algo would make sense so that there is at least a fair chance that both will use the same algo/values and get most out of this.
> 
First shot an an algorithm:

5.  Example Algorithm for Choosing the Local Preference

   The value space for the local preference is from 0 to 65535
   inclusive.  This value space can be divided up in chunks for each IP
   address family.

   An IPv6 and IPv4 start priority must be given.  In this example IPv6
   starts at 60000 and IPv4 at 59000.  This leaves enough address space
   to further play with the values if pr interface priorities needs to
   be added.  The highest value should be given to the address family
   that should be prioritized.

        IPv6    IPv4
         Start   Start
   65535  60k     59k    58k    57k    56k    55k                    0
   +--------+------+------+------+------+------+---------------------+
   |        | IPv6 | IPv4 | IPv6 | IPv4 | IPv6 |                     |
   |        | (1)  |  (1) |  (2) |  (2) |  (3) |                     |
   +--------+------+------+------+------+------+---------------------+
             <- N->

         
   The local preference can be calculated by the given formula:


         local_preference = N*2*(Cn/Cmax)

   Where N is the absolute value of IPv6_start-IPv4_start.  This ensures
   a positive number even if IPv4 is the highest priority.  Cn is the
   number of current candidates of a specific IP address type and
   candidate type (HOST, SRFLX, RELAY).  Cmax is the number of allowed
   consecutive candidates of the same IP address type.



.-.
Pål-Erik

> 
> Cheers,
> Ari
>