Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?)

Justin Uberti <juberti@google.com> Wed, 30 July 2014 21:00 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 7F4691A046A for <mmusic@ietfa.amsl.com>; Wed, 30 Jul 2014 14:00:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level:
X-Spam-Status: No, score=-1.379 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, RP_MATCHES_RCVD=-0.001, 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 lbi7gC9EA-gJ for <mmusic@ietfa.amsl.com>; Wed, 30 Jul 2014 14:00:09 -0700 (PDT)
Received: from mail-vc0-x234.google.com (mail-vc0-x234.google.com [IPv6:2607:f8b0:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 888BE1A040A for <mmusic@ietf.org>; Wed, 30 Jul 2014 14:00:09 -0700 (PDT)
Received: by mail-vc0-f180.google.com with SMTP id ij19so2807731vcb.39 for <mmusic@ietf.org>; Wed, 30 Jul 2014 14:00:08 -0700 (PDT)
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=19PRUHmGeGXBSvB58x1DPyzwdxhDASlI3diL+gCIV6s=; b=p1uKp3s62YPnT2RnRLd3nEyakmhTHLFNXzsfr5FpGx31PpZKz0HmMlYe//+4fLv6uA 5YxcpkNE1Gv+F06Wm44mJY4CODNWv8PAstsWrJ4zC0ILI3DUKzhDwUaEDY2fNM7s0HPZ WyuDlCmCvV+6Ox7IxdYRDZRp489MfBZVHEE9HBTXVSOzkPw7HRKnu440kFh9Ae0zRLEL lLnw1l3oOKrRTSppL4LydQPyUSUZtf9bxlwGIJqJgk03WZT5tD5i43MPQtEKkxsOjYGc Aiu6S6zgDyEd3EFe/GNUjhJXcfZiYMoQwI0GvNRPKRt2S5fKnA5TeIIwJOCquhrj24XK scWw==
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=19PRUHmGeGXBSvB58x1DPyzwdxhDASlI3diL+gCIV6s=; b=PeuGcdt8n2hyn0AtA/ZG/lOF5F4pCUbAaI8krv8NXjoLbIouivkvy2+8/GsWl1grrM sddPV/zkNZr5IdGctQI0SrydPY9ydKfNy1W7ihZ78rW1wYaZ2dcZb9BM7BGK/2MLEEl7 JyUXCQ28Uu6UYtuGgHa0HtiOR+suRhsAxMGawFz0gKZGaAugQqjg2zej9eq7Vms9A2YZ hntV3LgA1gctFR/z4Jf+Sp2JNMSW3Y9UPKli2ErrzZCieYZS8rP+94lN4jDmWxQqpJr8 Tv7Cc/lPlx/71r/cIHeVD+PZbI4JKZxnayHCbg/kIlCNlzN12CHc6XFz1HazAN6EzCBj udqA==
X-Gm-Message-State: ALoCoQlPzpEW21kiz9hCJZjmOz0dpOIGOMxGApZnr7Jfnb60tLWygwUtGaukNKE9pP6PId1/f8FJ
X-Received: by 10.52.136.196 with SMTP id qc4mr10886638vdb.22.1406754008550; Wed, 30 Jul 2014 14:00:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.133.193 with HTTP; Wed, 30 Jul 2014 13:59:48 -0700 (PDT)
In-Reply-To: <8D2E9E91-B0B7-4081-B65B-EDAEC4D23A97@vidyo.com>
References: <0DA61D09-6491-4DA4-8B6F-CFED70584A76@vidyo.com> <CAOJ7v-1jLK7dWDkWHKwHJ6qXicZWDNrAqOtw9R=6zAcWzkh5+g@mail.gmail.com> <53D796E5.9040009@jive.com> <2AF26344-DF5D-493C-96BC-80AD7DF35444@vidyo.com> <CAOJ7v-0HEjQQ+j0cAVc5r3Y4LxaoGF7EN2twGG6vTuMmEeragQ@mail.gmail.com> <8D2E9E91-B0B7-4081-B65B-EDAEC4D23A97@vidyo.com>
From: Justin Uberti <juberti@google.com>
Date: Wed, 30 Jul 2014 13:59:48 -0700
Message-ID: <CAOJ7v-1HzGoUNXjvXph0-8WfpM6-vFJ+yDWhVw1_1grfrVD1Vw@mail.gmail.com>
To: Jonathan Lennox <jonathan@vidyo.com>
Content-Type: multipart/alternative; boundary=bcaec51b12bdf77ea704ff6f7081
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/aACCzq-VmszoLlUwWcRPFhMuxHc
Cc: mmusic <mmusic@ietf.org>
Subject: Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?)
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: Wed, 30 Jul 2014 21:00:11 -0000

On Wed, Jul 30, 2014 at 8:10 AM, Jonathan Lennox <jonathan@vidyo.com> wrote:

>
> (Moving this discussion to MMusic.  I suggest further discussion drop the
> tram list, unless it cycles back around to a TURN-specific issue.)
>
> On Jul 29, 2014, at 1:57 PM, Justin Uberti <juberti@google.com> wrote:
> >
> > The one thing we need to do is update ICE to allow the CONTROLLING side
> to make dynamic decisions about which pair to use, instead of being forced
> to use PRIORITY (which is what 5245 says). I am going to try to write this
> up before Hawaii.
>
> This is equivalent to using regular nomination, but saying that an
> endpoint can send media on any Confirmed candidate pair, not just the
> Selected one, right?
>

It's a bit more than that - the controlled endpoint has to also synchronize
on the candidate pair, which means that it needs to know what its selected
pair should be, using logic other than what is outlined in
http://tools.ietf.org/html/rfc5245#section-11.1.1 (which says use the
highest priority nominated pair).

So it becomes:
- controlling side can pick any nominated candidate pair it wants to be its
selected pair
- controlled side should use presence of media from controlling side to
decide selected pair (for secure media), or some TBD attribute (for
non-secure media)
- controlling side can tell controlled side when it is OK to discard
candidate pairs that it has nominated (so that the controlling side can
still safely do the switch to a new pair). This is probably done by having
the controlled side keep all candidates alive that have received a check
from the controlling side in the past XX seconds.

>
> 5245 says that an ICE endpoint MUST be prepared to receive media on any
> candidate, but only sends on the Selected candidate pair.  I don’t know if
> this means, in practice, that ICE-bis could change to the behavior I’ve
> described above and still be backward compatible, or if there’d need to be
> some sort of ice-option negotiation to indicate that this early media (oh,
> dread phrase) is acceptable.
>

Yes, I think we need a new ICE option, or else old ICE impls in the
controlled role will be surprised when they think the selected pair is A
but media arrives on B. We've already seen a number of implementations have
issues with this.