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

Jonathan Lennox <> Wed, 30 July 2014 22:20 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 49E391A01AA for <>; Wed, 30 Jul 2014 15:20:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.13
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jvva6x-1a0Ne for <>; Wed, 30 Jul 2014 15:20:56 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 865CE1A00E8 for <>; Wed, 30 Jul 2014 15:20:56 -0700 (PDT)
X-Note-AR-ScanTimeLocal: 7/30/2014 6:20:53 PM
X-Policy: GLOBAL -
X-Policy: GLOBAL -
X-Policy: GLOBAL -
X-Note: This Email was scanned by AppRiver SecureTide
X-Virus-Scan: V-
X-Note-SnifferID: 0
X-Note: TCH-CT/SI:0-230/SG:5 7/30/2014 6:20:18 PM
X-GBUdb-Analysis: 0,, Ugly c=0.900414 p=-0.977539 Source White
X-Signature-Violations: 0-0-0-15963-c
X-Note-419: 15.6004 ms. Fail:0 Chk:1335 of 1335 total
X-Note: SCH-CT/SI:0-1335/SG:1 7/30/2014 6:20:48 PM
X-Note: Spam Tests Failed:
X-Country-Path: ->UNITED STATES->
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 [] (HELO by (CommuniGate Pro SMTP 6.0.8) with ESMTPS id 117160469; Wed, 30 Jul 2014 18:20:53 -0400
Received: from ([fe80::50:56ff:fe85:6b62]) by ([fe80::50:56ff:fe85:4f77%13]) with mapi id 14.03.0195.001; Wed, 30 Jul 2014 17:20:52 -0500
From: Jonathan Lennox <>
To: Justin Uberti <>
Thread-Topic: Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?)
Thread-Index: AQHPrAhtxaTuo9vyTE6R2p2YHkJufJu5biYAgAAEI4CAAAyGAIAABf0A
Date: Wed, 30 Jul 2014 22:20:51 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_4877642385944133BD233EA561EC2A9Dvidyocom_"
MIME-Version: 1.0
Cc: mmusic <>
Subject: Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 30 Jul 2014 22:20:58 -0000

On Jul 30, 2014, at 5:59 PM, Justin Uberti <<>> wrote:

On Wed, Jul 30, 2014 at 2:14 PM, Jonathan Lennox <<>> wrote:
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.

Oh, that’s true, it has to pick something.

In the semantic I’m suggestion, I think it doesn’t matter what it picks — it could choose any valid pair, just like the controlling agent does, since it knows that’s a working round-trip path.

For both sides, if you receive media on any candidate (from an IP and port from which you’ve received a valid connectivity check), accept it.  USE-CANDIDATE is then just an optimization that lets you close down the unselected candidates.

I don’t think you want a rule of “most recently received USE-CANDIDATE” to determine the selected pair.  Checks will race each other, especially when the paths’ RTTs are very different.

In my model, there is only ever one USE-CANDIDATE sent per component — i.e., it works like pure regular nomination, except for the “early media”.

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.

These are all in cases when the controlling endpoint is using aggressive nomination, though, right?  Do you have any data for regular nomination, i.e. media received before any USE-CANDIDATE attribute?