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
>