IETF Logo Mail Archive

Re: [MMUSIC] Faster ICE by role reversal?

Bernard Aboba <bernard_aboba@hotmail.com> Sun, 09 November 2014 19:11 UTC

Return-Path: <bernard_aboba@hotmail.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 451B31A6F44 for <mmusic@ietfa.amsl.com>; Sun, 9 Nov 2014 11:11:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.494
X-Spam-Level:
X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] 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 sjbeSlF1o_IU for <mmusic@ietfa.amsl.com>; Sun, 9 Nov 2014 11:11:22 -0800 (PST)
Received: from BLU004-OMC1S13.hotmail.com (blu004-omc1s13.hotmail.com [65.55.116.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F8FB1A6F38 for <mmusic@ietf.org>; Sun, 9 Nov 2014 11:11:22 -0800 (PST)
Received: from BLU406-EAS274 ([65.55.116.9]) by BLU004-OMC1S13.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Sun, 9 Nov 2014 11:11:21 -0800
X-TMN: [irUOqEdJbHOTljzbzeOsdFHf0GlFJKg6]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: <BLU406-EAS2743A5E6A5ADCEBF347F5C893830@phx.gbl>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
From: Bernard Aboba <bernard_aboba@hotmail.com>
MIME-Version: 1.0 (1.0)
Date: Sun, 09 Nov 2014 07:41:13 -1000
References: <CABkgnnVrXKz-7M_Qn7pSZBxCJTdQYPDOcEzrEbbv6eYrQs1Dhg@mail.gmail.com> <67A963F0-3667-47A7-B116-4712BA1147AD@vidyo.com> <CABkgnnV+ARP5xC-z=3AshUObUX_m3uisLY6NcsgEZVq-1drU8Q@mail.gmail.com> <DD8DA86E-3C6A-44A7-B4E1-92CC0742369D@vidyo.com> <CAOJ7v-1OpbtEujbp4rZOnmOxXB2hoTfjtn5U_kR5wML5sXD_4Q@mail.gmail.com> <545911E9.3070300@ericsson.com> <CAOJ7v-2ikhh+2Y5avJOjR=86UikOfSo169k3jSvFsU=52o3+zw@mail.gmail.com> <CAOJ7v-1oS999xAd52ANcWfW98Dq7nPJV0=1Z5o9fPigFaT7+1w@mail.gmail.com> <CABkgnnVCpRJUdKn34jsds1Dwe8nOA8uoJw4T35ogQ-LTtyb4Rg@mail.gmail.com> <CAPvvaaKeozeL=M1MvmveR-jkptEcheVewBoV04jS5aN6ghb76A@mail.gmail.com> <CABkgnnURgnkU+CWkCRzo2oKbV-pQnP0eLRZMouSNTWuk8TJ8+w@mail.gmail.com> <CAPvvaa+FKe+9FoegxCByAHj0d9aL2nLz10AK6HjX5Ao9PsgYMw@mail.gmail.com> <CABkgnnXUazQA6TWFDY=DPn6neoPbh5+=oUBW4cYjj_0dV0FaaA@mail.gmail.com> <CAOJ7v-13fyrkhyJQJvuGuWjHRFm9KO=-tQ7KLrFt0DW4U1K=RA@mail.gmail.com> <545EC85E.8000208@jitsi.org>
To: Emil Ivov <emcho@jitsi.org>
In-Reply-To: <545EC85E.8000208@jitsi.org>
X-OriginalArrivalTime: 09 Nov 2014 19:11:21.0821 (UTC) FILETIME=[F2CE18D0:01CFFC50]
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/I3JYC35g3gL7W0psYZ_eqfsfaZg
Cc: Jonathan Lennox <jonathan@vidyo.com>, Ari Keränen <ari.keranen@ericsson.com>, mmusic <mmusic@ietf.org>, Dan Wing <dwing@cisco.com>
Subject: Re: [MMUSIC] Faster ICE by role reversal?
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: Sun, 09 Nov 2014 19:11:28 -0000

On Nov 8, 2014, at 3:50 PM, Emil Ivov <emcho@jitsi.org> wrote:
>> 
> 
> Continuous nomination has at least two serious problems:
> 
> a) we lose the possibility to clearly detect failures and we need to resort to magic timers
> b) it is no longer clear when unused candidates (srflx and relay) can be released.

[BA] Justin's proposal does provide a way to know when unused candidates can be released. The problem is that those released candidates might actually be needed after a new interface comes up.

For example, say two peers are initially on the same WiFi LAN so that host candidate checks work.  As a result, there is no reason for either peer to keep unused relay candidates. Media is flowing, then one peer senses WiFi signal strength decreasing so it brings up an LTE interface. While it can trickle the new host, srflx and relay candidates, the other peer no longer has functioning relay candidates so the checks could fail.  While the peer could have kept its LTE interface hot all along and used it to ensure that the other peer kept its relay candidates that would have a high cost in terms of energy usage.

v2.23.0 | Report a Bug | By Email