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:59 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 476681A0422 for <mmusic@ietfa.amsl.com>; Wed, 30 Jul 2014 14:59:54 -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 O43yzKazkv_4 for <mmusic@ietfa.amsl.com>; Wed, 30 Jul 2014 14:59:51 -0700 (PDT)
Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 599431A016C for <mmusic@ietf.org>; Wed, 30 Jul 2014 14:59:48 -0700 (PDT)
Received: by mail-vc0-f169.google.com with SMTP id le20so2872242vcb.14 for <mmusic@ietf.org>; Wed, 30 Jul 2014 14:59:47 -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=UmaFJnEfhQ2vq45/fQ4TPRh8sWQYxlBpk8pQfP47cb0=; b=mTSOe2RG072w/foYp8arNW26XrNAehJFHrYxnZcwmPmYi3pSoPOHTnKOJ9L+CDQoov uAP0c784G0kFDxLVxNdZvpX5DL9YBCZ54l/DAxVfdOCqtl+NKop6MwL26+7qg80o5BVk m3bA2pEP440jovRqcD+YXb0qEPIb5VYR4yX9+nICYuPqZt2Zprh1uTffaX5L7J1VOdCs i4QAQGdcO7UB03FjtY9o3HFZvcc0x/vgnzkEI5jru6EvkpOLoUnWGWRhDPa8+S6qO6GU AdQNgsW3qHRJWegHf8Mk86QcaIrueYTCHt56mZu4BeXqk2vITwucXcE+ojSv+3M1EK0S fkCw==
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=UmaFJnEfhQ2vq45/fQ4TPRh8sWQYxlBpk8pQfP47cb0=; b=BFYuh8v3+ue17I/84QJnYehMLk6bFTndnaDY4rdVQHcXOZPnDTVDlZTbwLS18kEW1d hLIdupAlSVDY2xM6KT9+bi7RKuUXauui99sEWnMn6Xpn831SOXIHXj8pVG84KATbpBVV os+quNlOz0SKFDihsWWXnqjLCA3Tk4EElsv/GUgT33GRRen7d4FyaFBxxEW9zj6lcRqV H4kbQp7aSVluLR65s/NM68cY2luj4L4ZWRVoK3wi1kXJ3FN29twmCg6vgAtjQnTYs0sv aCLqZpQViplpoe2LMHUjfamhNeJDhrZsNVLky1vqYf1/5fHsDBxjvVGUYyWjo29k019O HqOw==
X-Gm-Message-State: ALoCoQnS1dBcDiLe9Tgk9QEAVfKzPY4QgCVYGGd4V2VR6m8EgWgxIwawDCAi6PpEgAFew6bixJf2
X-Received: by 10.221.41.135 with SMTP id tu7mr6579562vcb.70.1406757587499; Wed, 30 Jul 2014 14:59:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.133.193 with HTTP; Wed, 30 Jul 2014 14:59:26 -0700 (PDT)
In-Reply-To: <B2794643-ADB5-4B66-98DC-841990C85437@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> <CAOJ7v-1HzGoUNXjvXph0-8WfpM6-vFJ+yDWhVw1_1grfrVD1Vw@mail.gmail.com> <B2794643-ADB5-4B66-98DC-841990C85437@vidyo.com>
From: Justin Uberti <juberti@google.com>
Date: Wed, 30 Jul 2014 14:59:26 -0700
Message-ID: <CAOJ7v-2O3TwNcsKqp48PjDRu+Yu_+jEurecbO2GctD4Hsuu+NA@mail.gmail.com>
To: Jonathan Lennox <jonathan@vidyo.com>
Content-Type: multipart/alternative; boundary=001a1133901c49dc4b04ff7046db
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/090JRG08imeRJUv6aojnYCvwLYQ
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:59:56 -0000

On Wed, Jul 30, 2014 at 2:14 PM, Jonathan Lennox <jonathan@vidyo.com> wrote:

>
>  On Jul 30, 2014, at 4:59 PM, Justin Uberti <juberti@google.com> wrote:
>
>   On Wed, Jul 30, 2014 at 8:10 AM, Jonathan Lennox <jonathan@vidyo.com>
> wrote:
>
>>
>> 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.
>
>
>  You’ve just reinvented regular nomination — your “TBD attribute” is
> regular nomination’s USE-CANDIDATE.
>

>  Thus the suggestion I’m making — do regular nomination, but allow media
> to be sent on any valid pair prior to selection.  (Yes, re-reading 5245, I
> should have said “Valid” rather than “Confirmed”.  I mis-remembered the
> terminology.)
>

Understood. But controlled side needs some way to know what pair it should
use to send media, so we need some way to indicate this. Would this be done
via USE-CANDIDATE? If so, we could end up with multiple USE-CANDIDATEs as
we figure out the ideal path to use, which doesn't fit exactly with regular
nomination as defined in 5245, but otherwise seems exactly like what I am
proposing. Basically, controlled side uses the pair that it most recently
received USE-CANDIDATE on as its selected pair.

>
>    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.
>
>
>  Do they have issues receiving media if there is no selected pair yet?
>  This would be nonconformant with 5245, but nevertheless wouldn’t surprise
> me.
>

Since the controlled side sends the ClientHello in the typical case, this
isn't usually a problem. The issue that is most often seen is that the
ServerHello comes from B instead of A and is ignored.