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 >
- [MMUSIC] Fwd: New Version Notification for draft-… Pal Martinsen (palmarti)
- Re: [MMUSIC] Fwd: New Version Notification for dr… Ari Keränen
- Re: [MMUSIC] New Version Notification for draft-r… Pal Martinsen (palmarti)
- Re: [MMUSIC] Fwd: New Version Notification for dr… Prashanth Patil (praspati)
- Re: [MMUSIC] New Version Notification for draft-r… Ari Keränen
- Re: [MMUSIC] New Version Notification for draft-r… Pal Martinsen (palmarti)
- Re: [MMUSIC] New Version Notification for draft-r… Ari Keränen
- Re: [MMUSIC] New Version Notification for draft-r… Pal Martinsen (palmarti)
- Re: [MMUSIC] New Version Notification for draft-r… Ari Keränen
- Re: [MMUSIC] New Version Notification for draft-r… Pal Martinsen (palmarti)
- Re: [MMUSIC] New Version Notification for draft-r… Ari Keränen