Re: [MMUSIC] Seriously, USE-CANDIDATE!!! in 5245bis

Ari Keränen <ari.keranen@ericsson.com> Wed, 23 July 2014 16:30 UTC

Return-Path: <ari.keranen@ericsson.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 0ED791A00F0 for <mmusic@ietfa.amsl.com>; Wed, 23 Jul 2014 09:30:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.601
X-Spam-Level:
X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 cgRieXTEz-EW for <mmusic@ietfa.amsl.com>; Wed, 23 Jul 2014 09:30:31 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6A281A0084 for <mmusic@ietf.org>; Wed, 23 Jul 2014 09:30:30 -0700 (PDT)
X-AuditID: c1b4fb3a-f79a36d000000ffa-ae-53cfe324749c
Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 53.C6.04090.423EFC35; Wed, 23 Jul 2014 18:30:28 +0200 (CEST)
Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.74) with Microsoft SMTP Server id 14.3.174.1; Wed, 23 Jul 2014 18:30:27 +0200
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 3525B11029C; Wed, 23 Jul 2014 19:30:28 +0300 (EEST)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 9A2BC589CC; Wed, 23 Jul 2014 19:30:39 +0300 (EEST)
Received: from dhcp-bcda.meeting.ietf.org (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 01B6B589C9; Wed, 23 Jul 2014 19:30:38 +0300 (EEST)
Message-ID: <53CFE322.5000508@ericsson.com>
Date: Wed, 23 Jul 2014 12:30:26 -0400
From: Ari Keränen <ari.keranen@ericsson.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Emil Ivov <emcho@jitsi.org>
References: <53CD7C04.8070106@jitsi.org> <53CE7D0A.4030406@ericsson.com> <53CE7DDD.5030406@jitsi.org> <53CEE1A7.7070202@ericsson.com> <CAPvvaaKohXq8cZjUaQR6VvhHZ+Lkzzk2sQUn+iwSp_H1W6qaSA@mail.gmail.com>
In-Reply-To: <CAPvvaaKohXq8cZjUaQR6VvhHZ+Lkzzk2sQUn+iwSp_H1W6qaSA@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+Jvja7K4/PBBus/G1ms2TmBxWLq8scs DkweS5b8ZPL4/yYwgCmKyyYlNSezLLVI3y6BK+NPX0DBJ9GKbT8eMDUwThXsYuTkkBAwkfix uo0JwhaTuHBvPVsXIxeHkMBRRomD855CORsYJe7v/MQK4exllPj04RIjhLOOUeL8i1tMcM7v J90sIMN4BbQlZu/8wQZiswioSvz+eRjMZhOwlVj96iZYjahAssSarZPYIeoFJU7OfAIWFxGQ l+huWwR2FLOAjMSMs41gtrCAjcSK5nXMEMtOMUq0LL0C1MDBwSkQKNG6Nw2i3kJi8ZuD7BC2 vETz1tnMEM+pSVw9twnMFgK65+q/V4wTGEVnIVk9C0n7LCTtCxiZVzGKFqcWF+emGxnppRZl JhcX5+fp5aWWbGIExsTBLb+tdjAefO54iFGAg1GJh/fB/vPBQqyJZcWVuYcYpTlYlMR5F56b FywkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBMV338YJZ96byCJb0+2cqyEyrWxrfZ5+yeIOP sXKPEEut6Z2CpHhGOd20PReWXgt83z7LeEZU+YxLM3yc74S5VinOq4tM1T25+vi8Kf/nWBZ2 nLP5vuadysayn5GdrrNvV8cbPVky1Ua8amfffBcdzSlT+Z7r1YmezHlfIM5a+JPJZ97uO+HG SizFGYmGWsxFxYkAfCrz/2oCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/EfAqZdTxZhHOWYxOTmhAlJ2yw6Q
Cc: mmusic <mmusic@ietf.org>
Subject: Re: [MMUSIC] Seriously, USE-CANDIDATE!!! in 5245bis
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, 23 Jul 2014 16:30:34 -0000

On 7/22/14 7:12 PM, Emil Ivov wrote:
>
> On 22 Jul 2014 6:11 PM, "Ari Keränen" <ari.keranen@ericsson.com
> <mailto:ari.keranen@ericsson.com>> wrote:
>  >
>  > On 7/22/14 11:06 AM, Emil Ivov wrote:
>  >>
>  >> On 22.07.14, 11:02, Ari Keränen wrote:
>  >>>
>  >>> Hi,
>  >>>
>  >>> On 7/21/14 4:45 PM, Emil Ivov wrote:
>  >>>>
>  >>>> In London we mentioned the option of adding a new attribute that,
> during
>  >>>> aggressive nomination, the controlling agent can use to notify its
> peer
>  >>>> that ICE processing is over and no more changes are going to be
>  >>>> attempted. This way controlled agents will no they can now release
>  >>>> resources.
>  >>>>
>  >>>> This could either be a new attribute (e.g.,
> USE-CANDIDATE-CONFIRMED) or,
>  >>>> as Justin suggested in an off-list discussion, we could have the
>  >>>> controlling agent send a second USE-CANDIDATE once aggressive
> nomination
>  >>>> converges.
>  >>>
>  >>>
>  >>> Did you consider using the updated offer to indicate that you're really
>  >>> done? This would require that you always send it (i.e., a slight
>  >>> modification to 5245), but that's something that has been already
>  >>> proposed to be updated for other purposes.
>  >>
>  >>
>  >> The point is to have all that information without involving signalling,
>  >> as is the case with regular nomination.
>  >>
>  >> Let me ask the question the other way. Is there any reason not to do
> this?
>  >
>  >
>  > Just the usual: are the benefits higher than the added complexity.
> Here, depending how it's done, the added complexity should be fairly low
> though.
>
> The complexity of having to handle that over signalling and the need to
> implement it on every sig protocol that ever dares to use ICE is
> arguably much higher than that of an extra attribute

Actually I meant the complexity of implementing something like this, and 
why to do/not to do this (in any way).

>  > For the benefits, currently with SIP you are allowed to release the
> not selected candidate resources after 3 seconds from concluding ICE
> (http://tools.ietf.org/html/rfc5245#section-8.3.1).
>
> And that is the whole point because currently with aggressive nomination
> you simply don't know exactly when ICE has concluded.

So if you assume aggressive ICE has concluded after you've got your 
first USE-CANDIDATE checks done (as the text currently says), and you 
stop doing keep-alives on all except the selected candidate pair and let 
your relayed and reflexive candidates die away. You still have some time 
to switch between the candidates since the candidates are still alive 
for at least some (tens of?) seconds. Isn't that OK?

Or did you have some other kind of resources in mind?


Cheers,
Ari