Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?)

Emil Ivov <emcho@jitsi.org> Thu, 31 July 2014 20:30 UTC

Return-Path: <emcho@sip-communicator.org>
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 D07361A0142 for <mmusic@ietfa.amsl.com>; Thu, 31 Jul 2014 13:30:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 K4atO-kSmjw4 for <mmusic@ietfa.amsl.com>; Thu, 31 Jul 2014 13:30:30 -0700 (PDT)
Received: from mail-vc0-f177.google.com (mail-vc0-f177.google.com [209.85.220.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 070561A00FE for <mmusic@ietf.org>; Thu, 31 Jul 2014 13:30:29 -0700 (PDT)
Received: by mail-vc0-f177.google.com with SMTP id hy4so5024441vcb.36 for <mmusic@ietf.org>; Thu, 31 Jul 2014 13:30:28 -0700 (PDT)
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:date :message-id:subject:from:to:cc:content-type; bh=h13/4I3OFfdbSRFLilGxCVWXHa8x9UgUl1LAayMP6hk=; b=XHp428ib1U1katOmONXXk8XCUuZHjLGDwPqGH4m9U0Jey11elWDwbIsS85T1NIdTMt 31Qg+Bk5FbzVuaV0W+8MT0qIz8wp/OBCwNNH3rxssvlNksYIusAMusrWGWww0/5gY+A+ KvTT3NejZw4ua0RPq5Dy9gwS3pYb1i5xkPBHEMT90NeHqZwJ6Vqr3NFD5mFYtNMxw1/h gKYoStqoBqcXHwbH75cj7gpLRG3RiaWmqXGexOVB6ulVfTXfRBk025Mx5c9uyB3xlw8K n9JDzKZs6M9lkIhFAxtNFvsd7VQSPhFQMMsLkUAG+m6sY8LdAKBMULteI2ACPbJibgHB mwZA==
X-Gm-Message-State: ALoCoQnC+AA6uGrnjyFv8buOWwGW66zVOjI9CgNdCfRu0fu3Ig/C5h91NI5j1RbPL1GbAUScX6GL
X-Received: by 10.221.44.131 with SMTP id ug3mr1004219vcb.40.1406838628252; Thu, 31 Jul 2014 13:30:28 -0700 (PDT)
Received: from mail-vc0-f173.google.com (mail-vc0-f173.google.com [209.85.220.173]) by mx.google.com with ESMTPSA id xb6sm16022874vdc.19.2014.07.31.13.30.27 for <mmusic@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 31 Jul 2014 13:30:27 -0700 (PDT)
Received: by mail-vc0-f173.google.com with SMTP id hy10so5161923vcb.4 for <mmusic@ietf.org>; Thu, 31 Jul 2014 13:30:27 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.220.131.207 with SMTP id y15mr1000695vcs.71.1406838627186; Thu, 31 Jul 2014 13:30:27 -0700 (PDT)
Received: by 10.221.2.199 with HTTP; Thu, 31 Jul 2014 13:30:27 -0700 (PDT)
Received: by 10.221.2.199 with HTTP; Thu, 31 Jul 2014 13:30:27 -0700 (PDT)
In-Reply-To: <CAPvvaaJDT0cgWhNkeKMKWUnHvRgZaEb9VXjV3+wHCx15_Z6+wg@mail.gmail.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> <CAOJ7v-13UZi4w7Vfr2dkghaosrwVYkTw5G2shq0JUvLPy30vTw@mail.gmail.com> <CAOJ7v-0s6EVa4KxQY99wB-BaDGr5EZwVunxrW4BBgVJLEuWhiQ@mail.gmail.com> <CAPvvaa+sKWtGSaWvo6Vx=vhMbbhmLQKr2o9Z3Wjkm2-5TXDjHw@mail.gmail.com> <CAPvvaaJDT0cgWhNkeKMKWUnHvRgZaEb9VXjV3+wHCx15_Z6+wg@mail.gmail.com>
Date: Thu, 31 Jul 2014 22:30:27 +0200
Message-ID: <CAPvvaaLNjZr-3NmdJOAV-Ov6qQ1gZoEOF1dk4W52gEOUq4214g@mail.gmail.com>
From: Emil Ivov <emcho@jitsi.org>
To: Justin Uberti <juberti@google.com>
Content-Type: multipart/alternative; boundary=001a11348c2ea153f504ff83248c
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/N4gssFM2ZsPDCPSEGvuzyy37qnU
Cc: Jonathan Lennox <jonathan@vidyo.com>, 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: Thu, 31 Jul 2014 20:30:33 -0000

On 31 Jul 2014 9:18 PM, "Justin Uberti" <juberti@google.com> wrote:
>
>
>
>
> On Wed, Jul 30, 2014 at 4:23 PM, Justin Uberti <juberti@google.com> wrote:
>>
>>
>>
>>
>> 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.
>>>
>>> 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”.
>>
>>
>> OK, I get it now. I think the main issues you face are:
>> 1) Inability to selectively free candidates - all candidates except the
selected pair can be freed by the controlled side after USE-CANDIDATE.
>> 2) No guarantee of symmetric RTP - remote side can use a different pair
than local side - and you can't resolve this without USE-CANDIDATE (see #1).
>> 3) Potential issues when media arrives on non-nominated pair.
>>
>> Given #3, I think I'd prefer to find a solution that also addresses
#1/#2.
>
>
> Sounds like #3 is unlikely to be a problem given 5245 allows it.
>
> What do others think about #1/#2? These seem to be the main differences
between Jonathan's proposal and my proposal.

While #3 is indeed allowed by 5245 I don't think current regular nomination
implementations would actually handle things that way. (Except for those
that started with aggressive nomination as the default).

#1 and #2 can be important for ICE libs that just return a socket for the
app to use (the do need to know whem to return it)


 _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>