Re: [MMUSIC] Faster ICE by role reversal?

Justin Uberti <juberti@google.com> Thu, 06 November 2014 21:48 UTC

Return-Path: <juberti@google.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 843DC1A90C0 for <mmusic@ietfa.amsl.com>; Thu, 6 Nov 2014 13:48:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.672
X-Spam-Level:
X-Spam-Status: No, score=-1.672 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=no
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 JXVKdahRsX01 for <mmusic@ietfa.amsl.com>; Thu, 6 Nov 2014 13:48:19 -0800 (PST)
Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B420A1A90BF for <mmusic@ietf.org>; Thu, 6 Nov 2014 13:48:18 -0800 (PST)
Received: by mail-ob0-f181.google.com with SMTP id uy5so1647115obc.12 for <mmusic@ietf.org>; Thu, 06 Nov 2014 13:48:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Jb015phJcgZk1X+wLapgtWJUME2zzM0Tl6f+JzS6CDs=; b=S/2Z0rxWODBcznzAjnOdrxx/UxCm2JV7LEbLQ3DEwLHjgbRq5yK8qMtAnCSb0RiAxv HJmMObRpj2SANkf8rOAZNYuw3po8VrHyQh1Id8yMyV8zesq5FDv7HnCiQzZOd16ILUGY Bs3T9tuzrVPdnjxjE0+HB2G+MkRpqNFwoA4vOTIfjdJ6QchGZ3R1TbWJJSQSvbSqUtsz E+ulwDNZgJLfepUY0H4jafzeot57cvSi4mirGnvqdLDt4V23cuRfmUVcBTlXyG5DQQJV BioS165CuvMdeyFoiAIB32RQu1gm1X9fRAmw+o1UYQNFU2OHKxX+XO1hQK7ojvYYE5RU IaIw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Jb015phJcgZk1X+wLapgtWJUME2zzM0Tl6f+JzS6CDs=; b=LDQGJ0nIT6AzBX3dw7YyDxK9cD1IJ6MHhJMSRxWfpkOv75nQkFDYKyX1PeAZsr4xyp BviVLoDpl2tn3FdW0/3DOZRM6IkNL6MqBsQZXQH+91ratcAuoC4hr3dDFx9ZkcrfOPKL Fbj26czwPN1c5aMBz0/lPas6Zn2fM/ou3fmm9+PyVV9SxLfv1CzGhlagiuFkUC96jgdy JvxIvOAD1cIVr0lbN7vJA5cUaPD+iSW5AUdFFcIr4gQeN7GQzdykDCiCXVFpj+bZwRMR 8LI0EWWkXJmKfxSQbrZIIFZqU9mr1j+zLgpwQnlZIyjYDTDz7WyeMC18SSMAwjwChnX5 b/gg==
X-Gm-Message-State: ALoCoQmfSeP3JXz0XTKK8CuphBjkh4pb25rjTps58dUmpG+Rx3YCNe8iEKRpAccbkNIwcCCk1Q3m
X-Received: by 10.60.55.200 with SMTP id u8mr5828280oep.43.1415310497813; Thu, 06 Nov 2014 13:48:17 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.248.170 with HTTP; Thu, 6 Nov 2014 13:47:57 -0800 (PST)
In-Reply-To: <CAOJ7v-2ikhh+2Y5avJOjR=86UikOfSo169k3jSvFsU=52o3+zw@mail.gmail.com>
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>
From: Justin Uberti <juberti@google.com>
Date: Thu, 06 Nov 2014 13:47:57 -0800
Message-ID: <CAOJ7v-1oS999xAd52ANcWfW98Dq7nPJV0=1Z5o9fPigFaT7+1w@mail.gmail.com>
To: Ari Keränen <ari.keranen@ericsson.com>
Content-Type: multipart/alternative; boundary="089e011606ee783af7050737a7ca"
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/S8tGf-VDtXNIyH6U_5EkTRe0lzQ
Cc: Jonathan Lennox <jonathan@vidyo.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: Thu, 06 Nov 2014 21:48:20 -0000

On Thu, Nov 6, 2014 at 12:45 PM, Justin Uberti <juberti@google.com> wrote:

> I have been noodling on two proposals here:
>
> a) merging regular and aggressive nom
> -- essentially, Jonathan's suggestion from before:
> -- controlling side sends on any Valid pair, even prior to a pair being
> selected
> -- controlled side can send on any Valid pair (although it could use
> receipt of media to align with controlling side)
> -- controller confirms selection with use-candidate (same as today), which
> ends concludes ICE
> -- no ice-options needed (AFAICT)
>
> b) adding a new mode, "continuous" nomination
> -- ICE never concludes; controlling side is always able to change media
> path dynamically
> -- as a corollary, controlling side controls when remote candidates can be
> freed
> -- new candidates can be trickled at any time
> -- controlled side uses either receipt of (secure) media to align with
> controlling side, or receipt of new use-candidate checks
> -- this mode requires opt-in via ice-options:continuous
>
> I still need to look at how b) might overlap with MICE, but I'd be happy
> to write either of these up or present them in Honolulu.
>

I looked into how MICE works; I think that continuous nomination might be
able to effectively support that use case, as well as the case that Brandon
was interested in, namely picking the route that uses the best set of TURN
servers.

>
> On Tue, Nov 4, 2014 at 9:50 AM, Ari Keränen <ari.keranen@ericsson.com>
> wrote:
>
>> All,
>>
>> This feature seemed to get quite a bit of support.
>>
>> There were also some concerns about:
>>
>> * DTLS implementations *may* not like the fact that Hello comes from an
>> unexpected candidate (may also apply to other protocols?)
>>
>> * Whether (and when) the selected candidate is really firm and the others
>> can be freed, media on them discarded, or an ICE library can return a
>> socket that is bound to right candidate
>>
>> See also the threads:
>> http://www.ietf.org/mail-archive/web/mmusic/current/msg13596.html
>> http://www.ietf.org/mail-archive/web/mmusic/current/msg13656.html
>>
>> I'm planning to take this as a discussion item during the meeting, but
>> before that it would be great if the proponents of the change could come up
>> with a text proposal. I assume we'd need an ICE option to indicate this and
>> clarify what to do with data on a candidate without USE-CANDIDATE exchange.
>>
>> Also, if I missed some point why this would be a bad idea, please speak
>> now.
>>
>>
>>