Re: [MMUSIC] Continuous Nomination (Was: Faster ICE by role reversal?)

Varun Singh <vsingh.ietf@gmail.com> Mon, 10 November 2014 01:19 UTC

Return-Path: <vsingh.ietf@gmail.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 911441A87F0 for <mmusic@ietfa.amsl.com>; Sun, 9 Nov 2014 17:19:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.1
X-Spam-Level:
X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, J_CHICKENPOX_19=0.6, 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 0MDYbH091I5H for <mmusic@ietfa.amsl.com>; Sun, 9 Nov 2014 17:19:18 -0800 (PST)
Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCDF91A87E7 for <mmusic@ietf.org>; Sun, 9 Nov 2014 17:19:17 -0800 (PST)
Received: by mail-ie0-f178.google.com with SMTP id rp18so8364325iec.37 for <mmusic@ietf.org>; Sun, 09 Nov 2014 17:19:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=9LUuMnQ14/lZmeoiOdstK0Z0Jj5y9ey7b7kqxnijVE0=; b=oTVE9IuHl6Ir9NGgaCcje00HTmrdQBSxcFWpzbtEJlCVTIy7HVrJ316ES2gdeFskyx 1UcKrJOdg9SOgoFfH68fJ4qoiYA51EYD0f491poD9PKhMsgHFcOARMTtuSJS/HPpSRBv 4lDktle6urqEJmB8j9LzmdJ1xW0IyIU1sr2v9+GI515n9TYoHTln1J/rvrlq/qDkukk8 AHDuJX1pSbgzFhLqBqP2/eAfTInYgr1wvGPK39XnCyw4FKHvpqiQTOF4NSIWzeL5sbLU hbPaAzNW2yWHkElrRDA3GE4sGW8R3QaNCz6H+IY/FG956wwOSM9HbTvZU+4nYEcmB+pJ Gp1g==
X-Received: by 10.42.64.143 with SMTP id g15mr4800662ici.59.1415582357007; Sun, 09 Nov 2014 17:19:17 -0800 (PST)
MIME-Version: 1.0
Received: by 10.50.95.199 with HTTP; Sun, 9 Nov 2014 17:18:56 -0800 (PST)
In-Reply-To: <47B152C2-ED0C-4EB1-A15E-C81260D94D0F@cisco.com>
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> <47B152C2-ED0C-4EB1-A15E-C81260D94D0F@cisco.com>
From: Varun Singh <vsingh.ietf@gmail.com>
Date: Sun, 09 Nov 2014 15:18:56 -1000
Message-ID: <CAEbPqrypQC-wQL-O4VVie4_HgwZ3GQ16A1nKx-zJvYtGqLNSDw@mail.gmail.com>
To: 🔓Dan Wing <dwing@cisco.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/5w8XbvNFk92wSNNcR8HFTqzPsBE
Cc: Jonathan Lennox <jonathan@vidyo.com>, Ari Keränen <ari.keranen@ericsson.com>, mmusic <mmusic@ietf.org>
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: Mon, 10 Nov 2014 01:19:20 -0000

Catching up on the mailing list. One comment inline, reflecting on our
experiments with MPRTP.

On Fri, Nov 7, 2014 at 3:29 PM, 🔓Dan Wing <dwing@cisco.com> wrote:
>
> On 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.
>

Back in 2010, before we had trickle ICE, in Multipath RTP, we
implemented advertising the interfaces in RTCP, we wanted to do it
in-band with the media, because we wanted to avoid the SDP
offer/answer. It was more like a notification to the other party that
a new interface is available and that the endpoint wants to make use
of it. On receiving the RTCP message with the interface advertisement,
the endpoints would perform connectivity checks on the interfaces and
reported successful candidates to the RTP layer, and the scheduling
algorithm would figure out over time, which candidates should be
active/passive depending on the performance metrics (e.g., loss,
delay, throughput, etc.). OTOH, the application needs to know if any
paths work or else it would be stuck waiting for the transports to be
setup.

We tried not implementing ICE, but ended up doing something similar
anyway. Some of the early experiments are described in Section 7.1 of
MPRTP paper. [1]

[1] http://www.netlab.tkk.fi/~jo/papers/2013-mmsys-mprtp.pdf.

> I am slightly uncomfortable using signaling path for same reason, and signaling path takes longer to start up (TCP, TLS).  Even if we make the signaling path start up faster with all the spiffy new TLS 0-RTT or QUIC or whatever, the signaling path should remain slower because a server is involved and the path isn't as straight as the peer-to-peer path.  That's why MICE does not require to first send a=candidate over the signaling path.
>
>> 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're right, we don't know, of course.
>
> But same risk exists of the signaling path on a mobility event.
>
>
>> You signalling channel would be a safer bet, but more importantly, you'd likely want to tear down your call if it didn't.
>
> From my perspective, thinking about MICE, I want to make the mobility event (voice/video) successful.  If signaling takes a little while to get re-established, *shrug*, I don't care.
>

+1

>
>
>
>>
>>>> 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?
>
> It would help.  But multipath ICE requires I have that connection to TURN set up prior to the mobility event, right?  If I'm right, that is not desirable.
>
> -d
>
>
>>
>> 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
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic



-- 
http://www.netlab.tkk.fi/~varun/