IETF Logo Mail Archive

Re: [MMUSIC] Faster ICE by role reversal?

Martin Thomson <martin.thomson@gmail.com> Sun, 09 November 2014 19:29 UTC

Return-Path: <martin.thomson@gmail.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 663E11A6F64 for <mmusic@ietfa.amsl.com>; Sun, 9 Nov 2014 11:29:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 h-zD3Di4T-av for <mmusic@ietfa.amsl.com>; Sun, 9 Nov 2014 11:29:35 -0800 (PST)
Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB95C1A6F3F for <mmusic@ietf.org>; Sun, 9 Nov 2014 11:29:34 -0800 (PST)
Received: by mail-ob0-f178.google.com with SMTP id vb8so4709118obc.23 for <mmusic@ietf.org>; Sun, 09 Nov 2014 11:29:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=xoZ94Q5OwNoYdgzGogfGC0iX3Yg4EZNU9Y8xkWOfGz8=; b=eu3KlwOC3bLssXeuan8jQWw0BKs7Wx5QuOvWONEnV/7WnPcSsmmUpHYtpn93+ucKr+ TxQ71cwxowfgHeLOJF2UBxJuTtNteN3/TzxG0LdWH48FOuRTw5FR5z1kLCuS8LYKDB+9 Y/95e2p1lrNZZH0F87GUavHkmxHZ2CrLbIvfMac/mz8zfK6uM8sYMpPZXsc4/SkxwEQP Y0yJQOeFTaTpHTYhoG1eOiym96eRp/yWv9bWAf1UgyvVy83ipV97Bv8xrRBLAjx3ITIW gtoTENr7Y1rygVNu/70QpQRly0m3lR2UZIs+ABNsQqKLvnchSh5cULxygeh5XvUYm25i DiYw==
MIME-Version: 1.0
X-Received: by 10.202.63.137 with SMTP id m131mr3010807oia.75.1415561374037; Sun, 09 Nov 2014 11:29:34 -0800 (PST)
Received: by 10.60.42.210 with HTTP; Sun, 9 Nov 2014 11:29:33 -0800 (PST)
In-Reply-To: <BLU406-EAS2743A5E6A5ADCEBF347F5C893830@phx.gbl>
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> <BLU406-EAS2743A5E6A5ADCEBF347F5C893830@phx.gbl>
Date: Sun, 09 Nov 2014 11:29:33 -0800
Message-ID: <CABkgnnXrdeQEkDme5D2LgkLPDAurPbidyVKJEm6rq+PER9uMmA@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Bernard Aboba <bernard_aboba@hotmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/YzSuMpwQUsUEv1et-a7J0-vYj8U
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:29:36 -0000

On 9 November 2014 09:41, Bernard Aboba <bernard_aboba@hotmail.com> wrote:
> 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.


I think that this is the key problem.  And we need to start to
concentrate on the properties that we are looking for, rather than
looking dogmatically at one solution or other.  We need clear rules
(or an acknowledgment that there is a policy decision) around when a
given candidate can be released.  We probably also need rules or
mechanisms to support a reduction in testing of candidate pairs.

Emil's suggestion that you have some sort of explicit marker to
declare candidates dead or unusable is definitely worthwhile.  I
wonder if that's not better suited to something on the media path
though.

v2.23.0 | Report a Bug | By Email