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> Fri, 01 August 2014 23: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 2818B1A0199 for <mmusic@ietfa.amsl.com>; Fri, 1 Aug 2014 16:03:05 -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 69EyO7jJN4RJ for <mmusic@ietfa.amsl.com>; Fri, 1 Aug 2014 16:03:04 -0700 (PDT)
Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB8591A0174 for <mmusic@ietf.org>; Fri, 1 Aug 2014 16:03:03 -0700 (PDT)
Received: by mail-vc0-f175.google.com with SMTP id ik5so7696225vcb.20 for <mmusic@ietf.org>; Fri, 01 Aug 2014 16:03:03 -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=MWtdgPb35nFopA2D95+hne3whTqM+ECP+Q+6Mv3Afj8=; b=PGxExuDfLwk3q0bYHwZ3IuDjP8m0KsgX/EN4dGBw9eRJ408JqIpThUB7UriZC9Rkgn HoMi+RNQw7Zl7HpTHnB75JNQy28aSPw89sqG4iGLZbIn6t83+T7Iv+k7RkpGjFy/AnyQ eS4Pfvuft5jOahzIWoGGulHKqfKpcekVW9HzCBFjjXHc5+wuiFGa9R2b2LyvRRtwsS8r 2ot8ZdaEZzcabQkFsMm9TuK8qzqgpsGCnxjLJ8yTjV3teXSpIggTT6cS91W2N0vXWWvJ Zu3jYVA+Xq+1tiLxHX7833RjZcMMjmUltg4qM8nTDdRsPUhWGI/6zX5VCy4tw26RUZUA KV/w==
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=MWtdgPb35nFopA2D95+hne3whTqM+ECP+Q+6Mv3Afj8=; b=MznVMeIPWwjf5mtVpGR7ogyzmYGF1VklqI7z+3x/gDhGcWB5NowZU0H8AM9grgd/tC 9QbQH/bdg4LErkQzlaV2g28qTCG7btgK7Zj9VxeQ9I2LeTx0ctg8OTsy2+kC6naQX+FP 1KwhdRY7tDPxcUkj01keV3PyTS8V1MivmRVhLE4XrkJrZCZRgbMVn5Ft/fApqdVM6QXa UAztLVcLSNHxsmY1m+TvcbubxHWcBIKYI9pHsQu3mPylHT2I/Zl6RnMYaSQkgBVzo0Rx 3sW2dkuX+hlIqscGpX0NA6sBkQKR1RWj3GzcaagRU264sxtivjhD5b8lrGvrGI2Th11D 2opg==
X-Gm-Message-State: ALoCoQlnUgQ4FCf/kT4BvFQWN/0JsykkBf61I4C8BwJ+0sdxaYUxvJ+dJIW8uTMHsaO3asKdVyQs
X-Received: by 10.220.49.10 with SMTP id t10mr10335861vcf.34.1406934183018; Fri, 01 Aug 2014 16:03:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.133.193 with HTTP; Fri, 1 Aug 2014 16:02:42 -0700 (PDT)
In-Reply-To: <CABkgnnV0mBKgPj+9zNPcmTTLAGsz42eTMuAo14bnneSOowmR8w@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> <CAPvvaaLNjZr-3NmdJOAV-Ov6qQ1gZoEOF1dk4W52gEOUq4214g@mail.gmail.com> <CALiegf=QASGR2+FuY7TKoJYrdvqbDxyUyKxvMQ13do5YX4GUyw@mail.gmail.com> <CABkgnnXvs_7fjQfCjeXMn4_RZExc8mYAQzqvq_fznc+kwGkKqA@mail.gmail.com> <CALiegfmp5YJwO62+fUN8AB=-A8rbenko_P7r35jo_CdUT6MWbA@mail.gmail.com> <CABkgnnXzNVgrYK6gjWmdyBoJ1Cog45XTP7F3yzaqOmm=GTypzA@mail.gmail.com> <CAOJ7v-1wzU0yMs21XYOpersa9f8u0=1n-mJ1BNrO-rEu3x9K5w@mail.gmail.com> <CALiegf=DJVZgEruEEGY4J7YiQk1jpzcDkztrT+Nosyrbjn0q5g@mail.gmail.com> <CABkgnnV0mBKgPj+9zNPcmTTLAGsz42eTMuAo14bnneSOowmR8w@mail.gmail.com>
From: Justin Uberti <juberti@google.com>
Date: Fri, 1 Aug 2014 16:02:42 -0700
Message-ID: <CAOJ7v-0m9zpEiCSrMcibUjy1Q+BJJE0pVE4LJaN6jyhLzRjiPA@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Content-Type: multipart/alternative; boundary=089e0163412c33a5ce04ff996416
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/CI_X-Tq0aLf_RhS96hp1mz5Gvkc
Cc: mmusic <mmusic@ietf.org>, Jonathan Lennox <jonathan@vidyo.com>
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: Fri, 01 Aug 2014 23:03:05 -0000

On Fri, Aug 1, 2014 at 9:04 AM, Martin Thomson <martin.thomson@gmail.com>
wrote:

> On 1 August 2014 01:15, Iñaki Baz Castillo <ibc@aliax.net> wrote:
> > PS: In the text above I'm assuming that peerA initiates two different
> > DTLS handshakes over pair1 and pair2. In case bullet 2) is the way to
> > go, may we assume/mandate at least that peerA MUST perform a *single*
> > DTLS handshake (regardless packets are sent and received via pair1 or
> > pair2 or via both of them)?
>
> You can only have one DTLS connection, however...
>
> Sending two ClientHellos is OK, because DTLS requires retransmission
> of ClientHello to deal with packet loss.  The server should treat
> those as duplicates (and if they don't carry the same information, you
> are setting yourself up for failure when it comes to generating the
> Finished message).
>

Agreed. I don't understand why peerA would issue 2 *different* ClientHellos
to the two remote candidates; peerA only wants to establish a *single* DTLS
connection.