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

Justin Uberti <> Wed, 30 July 2014 23:23 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id EC6451A03E9 for <>; Wed, 30 Jul 2014 16:23:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.379
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8v15bsJt2cwc for <>; Wed, 30 Jul 2014 16:23:34 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E417C1A03E8 for <>; Wed, 30 Jul 2014 16:23:33 -0700 (PDT)
Received: by with SMTP id ij19so3033130vcb.39 for <>; Wed, 30 Jul 2014 16:23:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=kupduRGNgwetG5YF6O2djgk0XD0Ji0mWjxuu7piEb8M=; b=Gu9UAISqyEfLLixDmOMor/LPUEyPjGOkHrLqHXqOnI+iD89BGjDx5tnpqAiI9h8wQ2 sMtfYAswfA0ViN8nnJ7A0dqlqFHJur19PR3deVuz7WMguofaT5kEKiJ4ZR+nUXMTzB/a 88VDPwGK7k1bFaKONqwojBKjjJfBFtDQbc06IW12sgxEhutntnUSZjvje4Qry09wxCBU 7mJyzLb7ZawQTvVMHAYl+zvDlm+f+AzjFzRqz8qM9FeGb98KdkhLOW9cOz+NEJzv64R9 C6unRvyU0AUogJiuoMLTwyXDZWrw4l5Bdn26W2I1KmxvWWQ7W5M8za3JAh+gj1CeBigC hYPQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=kupduRGNgwetG5YF6O2djgk0XD0Ji0mWjxuu7piEb8M=; b=l7eMMy3BpgfRVxcvLz8CBAN3wdHnSU5C1mOa3N/fpmU21CAVoFvatE9eYATs6R1yzN UQldR/WdZLXEAcWsy+8KodtNj8c9v3nxb1quwRcTK4SxMKH4yy1pIb04/4ia8DMX1oNm JoTjpDqcyABiJcEF9uGk30LAXyijmYixW+H8GSWJVT5QaCbEC43v/iec07te5SZMMKHc n4rxFfztLWr78b/gIer4xJUQb6LdueVwa6Ooi9zUuqTNah5cDS6uC4je2z63nglxeBKr MuX4UMf1UncGKzPWo/Sa9Wp0EisKKr1rITilxPjYt5d4SDjOjPt/l9linAIHsSuEx3Cn GIng==
X-Gm-Message-State: ALoCoQkkEyYbe89qIDhl9hh9TfDkPl/68ynI/GuT++0Xw83zYBHZAJg1v5v4oT22N3qFi7suP9q7
X-Received: by with SMTP id tu7mr6961450vcb.70.1406762613030; Wed, 30 Jul 2014 16:23:33 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 30 Jul 2014 16:23:12 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <>
From: Justin Uberti <>
Date: Wed, 30 Jul 2014 16:23:12 -0700
Message-ID: <>
To: Jonathan Lennox <>
Content-Type: multipart/alternative; boundary=001a1133901cd569d104ff71710f
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 23:23:36 -0000

On Wed, Jul 30, 2014 at 3:20 PM, Jonathan Lennox <> wrote:

>  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”.

OK, I get it now. I think the main issues you face are:
1) Inability to selectively free candidates - all candidates except the
selected pair can be freed by the controlled side after USE-CANDIDATE.
2) No guarantee of symmetric RTP - remote side can use a different pair
than local side - and you can't resolve this without USE-CANDIDATE (see #1).
3) Potential issues when media arrives on non-nominated pair.

Given #3, I think I'd prefer to find a solution that also addresses #1/#2.

>       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?

Not at this time.