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 23:25 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 29D831A03F1 for <mmusic@ietfa.amsl.com>; Wed, 30 Jul 2014 16:25:31 -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 IA11LAtb5aJy for <mmusic@ietfa.amsl.com>; Wed, 30 Jul 2014 16:25:29 -0700 (PDT)
Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [IPv6:2607:f8b0:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22FC21A03C5 for <mmusic@ietf.org>; Wed, 30 Jul 2014 16:25:29 -0700 (PDT)
Received: by mail-vc0-f176.google.com with SMTP id id10so3029171vcb.7 for <mmusic@ietf.org>; Wed, 30 Jul 2014 16:25:28 -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=Z7r1fJdceZp6E/sjCDeoGa8oYarNJpaLQ66WYQfuZvo=; b=ZITY8VRk3Q9iPoKeATIuGkTf/e8c+IlYnNzsov2nyyRvOv/djyZ12LXzRXKNP6BU8q pg/44ZM1Okk0DR5jHJZH/OXHwYEbYHgr2cfFyhbKYZnkNar/Rc2zhKtHYKMIOCLdgsaw /sXlTiaHVfHwjt0AkaiM//KiQdz2V5cigETFJSIoeGNvLS2tmCLRZczzdMrjg21J7CXh w6DIjdJOqTdPOnyTpujGy9fcyT6xWwxPeAG1n7KK6hh6RwB/rXhh3uG8pri1wxaq07CE OUd/DvvQelGEdyHenp3rhHzfMHkk06BEMVE1Moge7GZdopUZQVfFYkCJxaFQJjW8IHm+ KpZw==
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=Z7r1fJdceZp6E/sjCDeoGa8oYarNJpaLQ66WYQfuZvo=; b=QxgAcehAGUE25jCWuIXT3cJZVuqex2k2AqKC93eLlnNCJslLUzRvoQ9sJX0BLTTdgF Qi9iQxdBJnVChG4oSqgIkWmIRRvQaO84oWngdLLLMSC7g9QBabznk695qAYuIi/6nbOE gCy5y7hvzxJZnWzcVok8nvOARGKFm/xXS0XO8L2KrTzS6/exWYamkIZpaOeXlD7pLLlD RO0xov1WdmCV39Xa8ZqfNmmOv3ANgsnjpIEJsAgeIOMYZgdjf5WvhkX6ptRs65jMd0Ti +x5c+PK9idYWI0LPQGTg7CuBXwSCPQXfWJZ8AkTzRFIK3w764azZ7IKVIIJtsNWna+cT lN8w==
X-Gm-Message-State: ALoCoQmh1UzDu693/c/Mi2XHcrfUelgb6ANZ3L3tOaEz4I8hly2Gw+KPA8+F0kkW8nWdDejBTeYo
X-Received: by 10.52.61.99 with SMTP id o3mr11478742vdr.46.1406762728349; Wed, 30 Jul 2014 16:25:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.133.193 with HTTP; Wed, 30 Jul 2014 16:25:08 -0700 (PDT)
In-Reply-To: <48776423-8594-4133-BD23-3EA561EC2A9D@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> <CAOJ7v-2O3TwNcsKqp48PjDRu+Yu_+jEurecbO2GctD4Hsuu+NA@mail.gmail.com> <48776423-8594-4133-BD23-3EA561EC2A9D@vidyo.com>
From: Justin Uberti <juberti@google.com>
Date: Wed, 30 Jul 2014 16:25:08 -0700
Message-ID: <CAOJ7v-1aF0L=fXSP6Fkb1nvukB8+mnKeYfbB9sMAUsufJpy-eg@mail.gmail.com>
To: Jonathan Lennox <jonathan@vidyo.com>
Content-Type: multipart/alternative; boundary="001a113403d0b4fdfc04ff717833"
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/XVqzV4N-J576whBWj1Dx-AmkdwE
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 23:25:31 -0000
On Wed, Jul 30, 2014 at 3:20 PM, Jonathan Lennox <jonathan@vidyo.com> wrote: > > On Jul 30, 2014, at 5:59 PM, Justin Uberti <juberti@google.com> wrote: > > On Wed, Jul 30, 2014 at 2:14 PM, Jonathan Lennox <jonathan@vidyo.com> > 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. > Agree, although this would be addressed by any of: - receipt of secure media is considered an indication of the selected pair - retransmit USE-CANDIDATE periodically on selected pair (need to do this for consent anyway) - REALLY-USE-CANDIDATE attribute > 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? >
- [MMUSIC] Merging ICE aggressive and regular nomin… Jonathan Lennox
- Re: [MMUSIC] Merging ICE aggressive and regular n… Martin Thomson
- Re: [MMUSIC] Merging ICE aggressive and regular n… Justin Uberti
- Re: [MMUSIC] Merging ICE aggressive and regular n… Justin Uberti
- Re: [MMUSIC] Merging ICE aggressive and regular n… Jonathan Lennox
- Re: [MMUSIC] Merging ICE aggressive and regular n… Emil Ivov
- Re: [MMUSIC] Merging ICE aggressive and regular n… Martin Thomson
- Re: [MMUSIC] Merging ICE aggressive and regular n… Justin Uberti
- Re: [MMUSIC] Merging ICE aggressive and regular n… Martin Thomson
- Re: [MMUSIC] Merging ICE aggressive and regular n… Justin Uberti
- Re: [MMUSIC] Merging ICE aggressive and regular n… Martin Thomson
- Re: [MMUSIC] Merging ICE aggressive and regular n… Jonathan Lennox
- Re: [MMUSIC] Merging ICE aggressive and regular n… Martin Thomson
- Re: [MMUSIC] Merging ICE aggressive and regular n… Jonathan Lennox
- Re: [MMUSIC] Merging ICE aggressive and regular n… Martin Thomson
- Re: [MMUSIC] Merging ICE aggressive and regular n… Justin Uberti
- Re: [MMUSIC] Merging ICE aggressive and regular n… Justin Uberti
- Re: [MMUSIC] Merging ICE aggressive and regular n… Iñaki Baz Castillo
- Re: [MMUSIC] Merging ICE aggressive and regular n… Iñaki Baz Castillo
- Re: [MMUSIC] Merging ICE aggressive and regular n… Iñaki Baz Castillo
- Re: [MMUSIC] Merging ICE aggressive and regular n… Justin Uberti
- Re: [MMUSIC] Merging ICE aggressive and regular n… Justin Uberti
- Re: [MMUSIC] Merging ICE aggressive and regular n… Emil Ivov
- Re: [MMUSIC] Merging ICE aggressive and regular n… Emil Ivov
- Re: [MMUSIC] Merging ICE aggressive and regular n… Iñaki Baz Castillo
- Re: [MMUSIC] Merging ICE aggressive and regular n… Iñaki Baz Castillo
- Re: [MMUSIC] Merging ICE aggressive and regular n… Iñaki Baz Castillo
- Re: [MMUSIC] Merging ICE aggressive and regular n… Martin Thomson
- Re: [MMUSIC] Merging ICE aggressive and regular n… Iñaki Baz Castillo
- Re: [MMUSIC] Merging ICE aggressive and regular n… Martin Thomson
- Re: [MMUSIC] Merging ICE aggressive and regular n… Justin Uberti
- Re: [MMUSIC] Merging ICE aggressive and regular n… Iñaki Baz Castillo
- Re: [MMUSIC] Merging ICE aggressive and regular n… Iñaki Baz Castillo
- Re: [MMUSIC] Merging ICE aggressive and regular n… Martin Thomson
- Re: [MMUSIC] Merging ICE aggressive and regular n… Justin Uberti
- Re: [MMUSIC] Merging ICE aggressive and regular n… Iñaki Baz Castillo
- Re: [MMUSIC] Merging ICE aggressive and regular n… Emil Ivov
- Re: [MMUSIC] Merging ICE aggressive and regular n… Iñaki Baz Castillo
- Re: [MMUSIC] Merging ICE aggressive and regular n… Emil Ivov
- Re: [MMUSIC] Merging ICE aggressive and regular n… Iñaki Baz Castillo
- Re: [MMUSIC] Merging ICE aggressive and regular n… Martin Thomson
- Re: [MMUSIC] Merging ICE aggressive and regular n… Iñaki Baz Castillo
- Re: [MMUSIC] Merging ICE aggressive and regular n… Iñaki Baz Castillo
- Re: [MMUSIC] Merging ICE aggressive and regular n… Justin Uberti
- Re: [MMUSIC] Merging ICE aggressive and regular n… José Luis Millán
- Re: [MMUSIC] Merging ICE aggressive and regular n… Martin Thomson
- Re: [MMUSIC] Merging ICE aggressive and regular n… Iñaki Baz Castillo
- Re: [MMUSIC] Merging ICE aggressive and regular n… Kevin Dempsey
- Re: [MMUSIC] Merging ICE aggressive and regular n… Iñaki Baz Castillo