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> Thu, 31 July 2014 19:18 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 90FE91A00C2 for <mmusic@ietfa.amsl.com>; Thu, 31 Jul 2014 12:18:36 -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 xIYBQ-bqPKz2 for <mmusic@ietfa.amsl.com>; Thu, 31 Jul 2014 12:18:34 -0700 (PDT)
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 986341A00DF for <mmusic@ietf.org>; Thu, 31 Jul 2014 12:18:34 -0700 (PDT)
Received: by mail-vc0-f174.google.com with SMTP id la4so5052484vcb.33 for <mmusic@ietf.org>; Thu, 31 Jul 2014 12:18:33 -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=W5CIPJrkHXn8E6p176xdNE0aOw9Rw9M/l9kDPkxLi+M=; b=NZ2an0BN5O8M6UfbgpcBEkJd+y7aZ3gtuc0co2cANJv7gSgZWjYIwYIQr/WvnqiZei pickFe0wcueNdj2tFjxz0iWa6dXuUZNXzbOdUSwupIZohn3hUd3nE5sp46ts9CSUg26u aaWFaBUMbGs15EzZv7GWYcHlAnxp/BB1Zz2toaAwMYwbuYYfirXrtu2b00e8aXBaPOVR 49xHq7VMfDGX53C78ZF4C65XabYzgKyX2BuiXlxgYHu0OlrCa+TotrOrcRNrKtIZGfr5 8tgcECQb9QLDeHcLC00V/2YAL3ZokZkeTgyVp6LXQ4PC2N/55SPNasniQ6bRnwXMlIOy KbdA==
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=W5CIPJrkHXn8E6p176xdNE0aOw9Rw9M/l9kDPkxLi+M=; b=Gyt49oeGsJyevcpx9W5hiwas55iHjnSlfsBbtpujKHcY6MrbqHLM0haAF8BeQb4c2B 3fXer5boZh46IqP4/N1CxsJW2S+bKYMq2QtL3+vlXs1jvgIFBcKX8IYPCORArh3Fg6wz jsyfEFex/51k/wn0heQ3oO3OZqdhv67vkyANUmffkX0iurEml4cM/igYGUI2h4Ec0LFp POKrBCcKlvTX/wR+NEY9MYyWzIb9Y4AknyyMVEik1JCmxGfbJHJVFspxlAoywXaKvuMa DDkYStHkSBrR2zGXOyde+7b3oAYfUoK4jhld3nyNH8IImZ6ALu2V8MnNc2yHLRa8mcQp xTsw==
X-Gm-Message-State: ALoCoQk+hOflOF7N0ZuCu6+5bhI2zxtemhSwW/h2rIEiG+10z4b04OWMFZu9jKgAllShkeKH4Evi
X-Received: by 10.52.28.9 with SMTP id x9mr342648vdg.48.1406834313714; Thu, 31 Jul 2014 12:18:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.133.193 with HTTP; Thu, 31 Jul 2014 12:18:13 -0700 (PDT)
In-Reply-To: <CAOJ7v-13UZi4w7Vfr2dkghaosrwVYkTw5G2shq0JUvLPy30vTw@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>
From: Justin Uberti <juberti@google.com>
Date: Thu, 31 Jul 2014 12:18:13 -0700
Message-ID: <CAOJ7v-0s6EVa4KxQY99wB-BaDGr5EZwVunxrW4BBgVJLEuWhiQ@mail.gmail.com>
To: Jonathan Lennox <jonathan@vidyo.com>
Content-Type: multipart/alternative; boundary=20cf307abebd86fb6304ff82230b
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/5s_HGiUOF-fAEt1kdIt-okP4JD8
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: Thu, 31 Jul 2014 19:18:36 -0000

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.