Re: [MMUSIC] Continuous Nomination (Was: Faster ICE by role reversal?)
Justin Uberti <juberti@google.com> Sat, 08 November 2014 02:03 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 370721A00FB for <mmusic@ietfa.amsl.com>; Fri, 7 Nov 2014 18:03:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.458
X-Spam-Level:
X-Spam-Status: No, score=-0.458 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.594, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] 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 FKKafOB23c9K for <mmusic@ietfa.amsl.com>; Fri, 7 Nov 2014 18:03:45 -0800 (PST)
Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20B901A00FD for <mmusic@ietf.org>; Fri, 7 Nov 2014 18:03:45 -0800 (PST)
Received: by mail-vc0-f174.google.com with SMTP id im17so2404459vcb.5 for <mmusic@ietf.org>; Fri, 07 Nov 2014 18:03:44 -0800 (PST)
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=jigy4i+n2GLBCPfs+CvR9lgJg9G7OSOd3s+C7TOVZAk=; b=nPJdR3zVcp7cECMO0Y11+9zBubNo754IKSO90XDPRcsDTKRJ/9bxsGt2C9FC4Csa38 RoxkSsX0NtwOvL/O2xUcSogJmnY6MtxoW/gspXXZQRHC3jXPwzIGXEXaXWW+9TV6Txb4 KN4wTcwtm/3155T05DxmyJDHgmQK0aBJwKucLABVcvQkPJm9hvoEHl990hY+J7px+1m5 d+MtxQwQ8STp8yFfpMz61rQuDmJlOT7RuGOIfAQPnSrrRl9/zWxlBid3eW4vsXNlDDFM kzGhdM2Khv+PxZRW9HkCVIZLZCmib+Pmni5w4RnLH+WrzxS0XvWNnPSRiRgpVQV+muDu yWVQ==
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=jigy4i+n2GLBCPfs+CvR9lgJg9G7OSOd3s+C7TOVZAk=; b=UZJxbJKHTQ4hlXHFD2FiMzp/uS+H/ec8s8fBQqWobjO7lGBDqwyH/jHtT8kFQo+c9s JD+cZz4cFTwNiwPo8e9YGCBZR18qoYgIfj5YMlbXxmteL1pgwj2CH3Ly22A5HiQ+XXOC xIvkjrB0/LRt1KScljB2m152bjSqaZYKPIYmrmokx1h48jXwZpnfFgydCHjnJbPhvYbL zu1LvwvEbOyRJH63ndqhZV1fQQlRRxi+fo8iPhn4OkM3c4pagyIHDMj/ubWGXIObe/iO YeEA9pVBhxqzx76QLGQzR2suq+Vf+ma4QNFfPw/pRmHVrfdyMc496rRbpliqC4a5eN8E i5wQ==
X-Gm-Message-State: ALoCoQnj+mrU/oNaCDrPglryPfuQwQco6IlKloF9NCJ9VyFP5FokRTxKde2kY5H3q66aKTNkQ8XE
X-Received: by 10.52.29.212 with SMTP id m20mr8535527vdh.34.1415412223950; Fri, 07 Nov 2014 18:03:43 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.237.130 with HTTP; Fri, 7 Nov 2014 18:03:23 -0800 (PST)
In-Reply-To: <545D6F6A.3020003@jitsi.org>
References: <CABkgnnVrXKz-7M_Qn7pSZBxCJTdQYPDOcEzrEbbv6eYrQs1Dhg@mail.gmail.com> <67A963F0-3667-47A7-B116-4712BA1147AD@vidyo.com> <CABkgnnV+ARP5xC-z=3AshUObUX_m3uisLY6NcsgEZVq-1drU8Q@mail.gmail.com> <DD8DA86E-3C6A-44A7-B4E1-92CC0742369D@vidyo.com> <CAOJ7v-1OpbtEujbp4rZOnmOxXB2hoTfjtn5U_kR5wML5sXD_4Q@mail.gmail.com> <545911E9.3070300@ericsson.com> <CAOJ7v-2ikhh+2Y5avJOjR=86UikOfSo169k3jSvFsU=52o3+zw@mail.gmail.com> <CAOJ7v-1oS999xAd52ANcWfW98Dq7nPJV0=1Z5o9fPigFaT7+1w@mail.gmail.com> <CABkgnnVCpRJUdKn34jsds1Dwe8nOA8uoJw4T35ogQ-LTtyb4Rg@mail.gmail.com> <CAOJ7v-1eG43K=vfSuLyuAs2W+_jPTaLpWRcGaCwo=v7XCcHSqA@mail.gmail.com> <545D4A84.1000608@jitsi.org> <42179677-E238-4EF8-8ED2-E7AA03661F05@cisco.com> <545D6F6A.3020003@jitsi.org>
From: Justin Uberti <juberti@google.com>
Date: Fri, 07 Nov 2014 18:03:23 -0800
Message-ID: <CAOJ7v-1PAnGLR0MB8Bv3PsCUfyCDyHQR5uvTEhyacZxOKdRJnQ@mail.gmail.com>
To: Emil Ivov <emcho@jitsi.org>
Content-Type: multipart/alternative; boundary="20cf3079b7ced1da5a05074f56da"
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/fwnkfW3R1nPIQ7R1OOZmQdE3DN8
Cc: Jonathan Lennox <jonathan@vidyo.com>, Ari Keränen <ari.keranen@ericsson.com>, mmusic <mmusic@ietf.org>, 🔓Dan Wing <dwing@cisco.com>
Subject: Re: [MMUSIC] Continuous Nomination (Was: Faster ICE by role reversal?)
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: Sat, 08 Nov 2014 02:03:49 -0000
It's getting hard to follow the idea here, so I suggest you write it up in a document and then we can try to find some time in Hono to sit down and discuss the pros/cons of continuous nomination and your approach. On Fri, Nov 7, 2014 at 5:18 PM, Emil Ivov <emcho@jitsi.org> wrote: > > > On 8.11.14, 1:35, 🔓Dan Wing wrote: > >> >> On Nov 7, 2014, at 2:41 PM, Emil Ivov <emcho@jitsi.org> wrote: >> >> Hey all, >>> >>> In the context of the ongoing discussion on two potential ICE >>> improvements, I wanted to spin off this thread on the idea of >>> continuous nomination. >>> >>> So first of all, as I already mentioned in Toronto, I am very much >>> in favour of a mechanism that would allow ICE processing to yield >>> more than a single nominated pair. Back then the discussion was >>> about MPRTP but there would likely be other use cases as well. >>> >>> In that context, it seems perfectly valid to me that nomination >>> among all validated pairs can occur multiple times within a >>> session. Again, I find this to be a very valid and useful feature. >>> >>> I am however bothered by the "ICE never ends" suggestions made by >>> the document below and more specifically by the fact that >>> candidates may continue to be trickled forever. I think that's both >>> unnecessary and a problem. >>> >>> It is a problem because >>> >>> a) being able to know when the remote agent is done trickling is >>> one of the very reasons we started the work on trickle ICE. This >>> allows to quickly and deterministically detect and declare failure >>> when it occurs. Not having this would require implementations to >>> use magic timers of the sort: "Surely if I couldn't connect in .. >>> say 20 seconds ... then the situation must be hopeless ... I >>> think". >>> >>> b) being able to continuously trickle new candidates forever and >>> ever means that they would have to be paired with all of the peer's >>> *initial* candidates. This means that ICE agents would have to >>> maintain all gathered candidates even when they are not working for >>> them. >>> >>> More importantly however, the whole concept is likely unnecessary >>> because an ICE restart only sounds scary, and it doesn't actually >>> need to be ;). >>> >>> A restart is non-disruptive as media can keep flowing while we are >>> doing ICE processing. >>> >>> 5245 already supports pair reuse and we can easily port that >>> concept to multipath ICE. >>> >>> The one thing that we might be missing today is the syntax to allow >>> for a restart without using offer/answer. >>> >> >> For MICE and some other use cases, I agree that need to signal (in >> SDP) is the 'scary' part of an ICE restart. >> >> This would be trivial to resolve: we just need to allow trickling a >>> restart command. Sending your ufrag and pwd in a trickle update >>> should do the job. >>> >> >> That is a nice approach -- move the 'ICE restart' signaling to an >> (existing, working) media path. >> > > I was actually thinking of the signalling path. So for SIP this would be a > SIP INFO request with the ufrag/pwd as the sole content. A couple of a= > lines would do it for WebRTC. > > I am slightly uncomfortable about doing it on the media path because it > requires you to make the assumption that one of your media paths is certain > to survive any sort of mobility event. > > Even if you keep your TURN connection open for that purpose, how do you > know that your new location wouldn't be one where TURN-TCP is the only way > to get out of the local network? > > Or what if you don't even have a TURN server? > > You signalling channel would be a safer bet, but more importantly, you'd > likely want to tear down your call if it didn't. > > > To put that into perspective, let's look at the following use >>> cases: >>> >>> I. You have used the new multipath ICE and you have successfully >>> discovered a couple of working routes: one going through your wi-fi >>> interface and another one going through 4G. During your session, >>> you move closer to your Wi-Fi access point so you detect that RTT >>> and packet loss start looking better on your Wi-Fi interface. >>> >>> You decide to switch from 4G to Wi-Fi. >>> >>> *No ICE restart* would be necessary here because no new paths would >>> need to negotiated. This would be a native feature of the new >>> multipath ICE. >>> >>> II. You start on Wi-Fi in the presence of a 4G interface that you >>> keep for backup. Multipath ICE comes up with pairs over both your >>> interfaces. I don't believe this requires an ICE restart either. >>> You just switch between pre-existing path and one of them expires >>> as pointed out in Justin's document below >>> >>> III. You setup a session at a point of time where 4G is your only >>> working interface. Your Wi-Fi interface then comes up and you want >>> to include it in the game. Here's what you do: >>> >>> a) You gather host, srflx and relay candidates for the new >>> interface. b) You gather candidates on the old interface that >>> haven't been valid before but that are worth trying again (this is >>> non-essential) >>> >>> d) you then trickle a new ufrag and pwd to trigger a restart. >>> >> >> If that trickling happens over the SIP/WebRTC/XMPP signaling channel, >> MICE would prefer not requiring that SDP signaling step or to at >> least allow it to be done later. >> > > Well, if you had multipath ICE, you would be able to switch your media > over to TURN (this wouldn't require any signalling) if that still works > and then do the non-disruptive restart after that to discover other paths. > > Would this work? > > Emil > > > >> -d >> >> >> b) you batch trickle all currently working candidates that you'd >>> wish to preserve (you can omit any candidates you no longer wish to >>> use, for whatever reason). c) you trickle the newly gathered >>> candidates. >>> >>> The remote party, your peer, would then do the following >>> >>> a) Gather all candidates that didn't work before but that deserve a >>> second chance. This time *this is essential*. SRFLX candiates on >>> your peer might not have worked with your 4G connection but they >>> have every chance of working this time. There are a number of other >>> scenarios where candidates would be worth retrying. >>> >>> b) Your peer would then trickle back to you all the working >>> candidates it wishes to preserve (as long as they are still valid) >>> c) It trickles all candidates it gathered for the occasion, that it >>> wishes to retry. >>> >>> Connectivity checks then proceed as usual. It might be worth paying >>> special attention to the in-use candidates. Implementations might >>> want to either confirm that data is still flowing there, or start >>> the checks with them. This would determine how urgently ICE >>> processing needs to yield results and it may imply changes in >>> nomination strategies. >>> >>> Thoughts? >>> >>> Emil >>> >>> >>> On 7.11.14, 0:44, Justin Uberti wrote: >>> >>>> Agreed. >>>> >>>> I wrote up a slightly more fleshed-out proposal at >>>> https://docs.google.com/document/d/1P1XPCRJKBkSjwCzIIEUJmp7V694_ >>>> FzJQe-fvN8bk-Xw/edit >>>> >>>> >>>> >>>> On Thu, Nov 6, 2014 at 3:29 PM, Martin Thomson < > martin.thomson@gmail.com > >> <mailto:martin.thomson@gmail.com>> wrote: >>>> >>>> On 6 November 2014 13:47, Justin Uberti <juberti@google.com >>>> <mailto:juberti@google.com>> wrote: >>>> >>>>> I looked into how MICE works; I think that continuous >>>>> nomination might be able to effectively support that use case, >>>>> as well as the case that Brandon was interested in, namely >>>>> picking the route that uses the best set of TURN servers. >>>>> >>>> >>>> >>>> I've always believe that continuous ICE operation was the only >>>> way to ensure proper reliability. Multipath or otherwise. You >>>> just need to work out when it is safe to completely stop on any >>>> given pair, assuming that you don't want to be testing the >>>> complete mesh all the time. But you also might want multiple >>>> paths available, or maybe backup paths. >>>> >>>> >>>> >>> -- https://jitsi.org >>> >> >> >> > -- > https://jitsi.org >
- Re: [MMUSIC] Faster ICE by role reversal? Jonathan Lennox
- [MMUSIC] Faster ICE by role reversal? Martin Thomson
- Re: [MMUSIC] Faster ICE by role reversal? Martin Thomson
- Re: [MMUSIC] Faster ICE by role reversal? Jonathan Lennox
- Re: [MMUSIC] Faster ICE by role reversal? Martin Thomson
- Re: [MMUSIC] Faster ICE by role reversal? Justin Uberti
- Re: [MMUSIC] Faster ICE by role reversal? Dan Wing
- Re: [MMUSIC] Faster ICE by role reversal? Martin Thomson
- Re: [MMUSIC] Faster ICE by role reversal? Dan Wing
- Re: [MMUSIC] Faster ICE by role reversal? Iñaki Baz Castillo
- Re: [MMUSIC] Faster ICE by role reversal? Martin Thomson
- Re: [MMUSIC] Faster ICE by role reversal? Ari Keränen
- Re: [MMUSIC] Faster ICE by role reversal? Justin Uberti
- Re: [MMUSIC] Faster ICE by role reversal? Justin Uberti
- Re: [MMUSIC] Faster ICE by role reversal? 🔓Dan Wing
- Re: [MMUSIC] Faster ICE by role reversal? Varun Singh
- Re: [MMUSIC] Faster ICE by role reversal? Martin Thomson
- Re: [MMUSIC] Faster ICE by role reversal? Justin Uberti
- Re: [MMUSIC] Faster ICE by role reversal? Emil Ivov
- Re: [MMUSIC] Faster ICE by role reversal? Martin Thomson
- Re: [MMUSIC] Faster ICE by role reversal? Emil Ivov
- Re: [MMUSIC] Faster ICE by role reversal? Justin Uberti
- Re: [MMUSIC] Faster ICE by role reversal? Ari Keränen
- [MMUSIC] Continuous Nomination (Was: Faster ICE b… Emil Ivov
- Re: [MMUSIC] Continuous Nomination (Was: Faster I… 🔓Dan Wing
- Re: [MMUSIC] Continuous Nomination (Was: Faster I… Emil Ivov
- Re: [MMUSIC] Continuous Nomination (Was: Faster I… Justin Uberti
- Re: [MMUSIC] Faster ICE by role reversal? Martin Thomson
- Re: [MMUSIC] Faster ICE by role reversal? Justin Uberti
- Re: [MMUSIC] Continuous Nomination (Was: Faster I… 🔓Dan Wing
- Re: [MMUSIC] Continuous Nomination (Was: Faster I… Emil Ivov
- Re: [MMUSIC] Faster ICE by role reversal? Emil Ivov
- Re: [MMUSIC] Faster ICE by role reversal? Emil Ivov
- Re: [MMUSIC] Faster ICE by role reversal? Justin Uberti
- Re: [MMUSIC] Faster ICE by role reversal? Emil Ivov
- Re: [MMUSIC] Faster ICE by role reversal? Bernard Aboba
- Re: [MMUSIC] Faster ICE by role reversal? Martin Thomson
- Re: [MMUSIC] Faster ICE by role reversal? Emil Ivov
- Re: [MMUSIC] Faster ICE by role reversal? Tirumaleswar Reddy (tireddy)
- Re: [MMUSIC] Continuous Nomination (Was: Faster I… Varun Singh
- Re: [MMUSIC] Faster ICE by role reversal? Varun Singh
- Re: [MMUSIC] Faster ICE by role reversal? Emil Ivov
- Re: [MMUSIC] Faster ICE by role reversal? Emil Ivov
- Re: [MMUSIC] Faster ICE by role reversal? Varun Singh
- Re: [MMUSIC] Faster ICE by role reversal? Martin Thomson
- Re: [MMUSIC] Continuous Nomination (Was: Faster I… Emil Ivov
- Re: [MMUSIC] Continuous Nomination (Was: Faster I… Justin Uberti
- Re: [MMUSIC] Continuous Nomination (Was: Faster I… Emil Ivov
- Re: [MMUSIC] Continuous Nomination (Was: Faster I… Justin Uberti