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

Jonathan Lennox <jonathan@vidyo.com> Wed, 30 July 2014 21:14 UTC

Return-Path: <jonathan@vidyo.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 1A1191A064A for <mmusic@ietfa.amsl.com>; Wed, 30 Jul 2014 14:14:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.13
X-Spam-Level:
X-Spam-Status: No, score=-1.13 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, 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 p-sTF71yi7hm for <mmusic@ietfa.amsl.com>; Wed, 30 Jul 2014 14:14:41 -0700 (PDT)
Received: from server209.appriver.com (server209e.appriver.com [8.31.233.120]) (using TLSv1 with cipher DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 950761A0648 for <mmusic@ietf.org>; Wed, 30 Jul 2014 14:14:41 -0700 (PDT)
X-Note-AR-ScanTimeLocal: 7/30/2014 5:14:38 PM
X-Policy: GLOBAL - vidyo.com
X-Policy: GLOBAL - vidyo.com
X-Policy: GLOBAL - vidyo.com
X-Primary: jonathan@vidyo.com
X-Note: This Email was scanned by AppRiver SecureTide
X-Virus-Scan: V-
X-Note-SnifferID: 0
X-Note: TCH-CT/SI:0-235/SG:5 7/30/2014 5:13:43 PM
X-GBUdb-Analysis: 0, 162.209.16.213, Ugly c=0.896023 p=-0.981919 Source White
X-Signature-Violations: 0-0-0-14664-c
X-Note-419: 15.5995 ms. Fail:0 Chk:1335 of 1335 total
X-Note: SCH-CT/SI:0-1335/SG:1 7/30/2014 5:14:33 PM
X-Note: Spam Tests Failed:
X-Country-Path: ->UNITED STATES->
X-Note-Sending-IP: 162.209.16.213
X-Note-Reverse-DNS: mail1.vidyo.com
X-Note-Return-Path: jonathan@vidyo.com
X-Note: User Rule Hits:
X-Note: Global Rule Hits: G335 G336 G337 G338 G342 G343 G453
X-Note: Encrypt Rule Hits:
X-Note: Mail Class: VALID
X-Note: Headers Injected
Received: from [162.209.16.213] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 143604675; Wed, 30 Jul 2014 17:14:38 -0400
Received: from 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62]) by 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77%13]) with mapi id 14.03.0195.001; Wed, 30 Jul 2014 16:14:37 -0500
From: Jonathan Lennox <jonathan@vidyo.com>
To: Justin Uberti <juberti@google.com>
Thread-Topic: Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?)
Thread-Index: AQHPrAhtxaTuo9vyTE6R2p2YHkJufJu5biYAgAAEI4A=
Date: Wed, 30 Jul 2014 21:14:37 +0000
Message-ID: <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>
In-Reply-To: <CAOJ7v-1HzGoUNXjvXph0-8WfpM6-vFJ+yDWhVw1_1grfrVD1Vw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [160.79.219.114]
Content-Type: multipart/alternative; boundary="_000_B2794643ADB54B6698DC841990C85437vidyocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/g2KndWEIMwQosvJJMqY0ZZ7HW1c
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:14:45 -0000

On Jul 30, 2014, at 4:59 PM, Justin Uberti <juberti@google.com<mailto:juberti@google.com>> wrote:

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

On Jul 29, 2014, at 1:57 PM, Justin Uberti <juberti@google.com<mailto: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.)

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.