Re: [MMUSIC] Faster ICE by role reversal?

Jonathan Lennox <jonathan@vidyo.com> Wed, 30 July 2014 23:05 UTC

Return-Path: <jonathan@vidyo.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 8F2211A01AA for <mmusic@ietfa.amsl.com>; Wed, 30 Jul 2014 16:05:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.131
X-Spam-Level:
X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, 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 JhrQ9kdl2KZb for <mmusic@ietfa.amsl.com>; Wed, 30 Jul 2014 16:05:27 -0700 (PDT)
Received: from server209.appriver.com (server209d.appriver.com [8.31.233.119]) (using TLSv1 with cipher DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0CE91A0080 for <mmusic@ietf.org>; Wed, 30 Jul 2014 16:05:26 -0700 (PDT)
X-Note-AR-ScanTimeLocal: 7/30/2014 7:05:25 PM
X-Policy: GLOBAL - vidyo.com
X-Policy: GLOBAL - vidyo.com
X-Primary: jonathan@vidyo.com
X-Note: This Email was scanned by AppRiver SecureTide
X-Virus-Scan: V-
X-Note-SnifferID: 0
X-Note: TCH-CT/SI:0-50/SG:2 7/30/2014 7:04:45 PM
X-GBUdb-Analysis: 0, 162.209.16.213, Ugly c=0.900165 p=-0.981666 Source White
X-Signature-Violations: 0-0-0-3697-c
X-Note-419: 0 ms. Fail:0 Chk:1335 of 1335 total
X-Note: SCH-CT/SI:0-1335/SG:1 7/30/2014 7:05:18 PM
X-Note: Spam Tests Failed:
X-Country-Path: ->UNITED STATES->
X-Note-Sending-IP: 162.209.16.213
X-Note-Reverse-DNS: mail1.vidyo.com
X-Note-Return-Path: jonathan@vidyo.com
X-Note: User Rule Hits:
X-Note: Global Rule Hits: G335 G336 G337 G338 G342 G343 G453
X-Note: Encrypt Rule Hits:
X-Note: Mail Class: VALID
X-Note: Headers Injected
Received: from [162.209.16.213] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 143631624; Wed, 30 Jul 2014 19:05:25 -0400
Received: from 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62]) by 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77%13]) with mapi id 14.03.0195.001; Wed, 30 Jul 2014 18:05:24 -0500
From: Jonathan Lennox <jonathan@vidyo.com>
To: Martin Thomson <martin.thomson@gmail.com>
Thread-Topic: [MMUSIC] Faster ICE by role reversal?
Thread-Index: AQHPrETDHXceLg7ZbU2lUKvim4SOLZu5jkoAgAABA4CAAAF2gA==
Date: Wed, 30 Jul 2014 23:05:23 +0000
Message-ID: <DD8DA86E-3C6A-44A7-B4E1-92CC0742369D@vidyo.com>
References: <CABkgnnVrXKz-7M_Qn7pSZBxCJTdQYPDOcEzrEbbv6eYrQs1Dhg@mail.gmail.com> <67A963F0-3667-47A7-B116-4712BA1147AD@vidyo.com> <CABkgnnV+ARP5xC-z=3AshUObUX_m3uisLY6NcsgEZVq-1drU8Q@mail.gmail.com>
In-Reply-To: <CABkgnnV+ARP5xC-z=3AshUObUX_m3uisLY6NcsgEZVq-1drU8Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [160.79.219.114]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <C97C03093257FD43B4B6B51D109183B4@vidyo.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/PV45Hr-_2WJIq5o2NnMYxTnQJMs
Cc: mmusic <mmusic@ietf.org>
Subject: Re: [MMUSIC] 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: Wed, 30 Jul 2014 23:05:29 -0000

On Jul 30, 2014, at 7:00 PM, Martin Thomson <martin.thomson@gmail.com> wrote:

> On 30 July 2014 15:56, Jonathan Lennox <jonathan@vidyo.com> wrote:
>> The offerer can’t send its own connectivity checks until it receives an answer, because it needs the remote ufrag and password.  Without this, it doesn’t have any valid pairs, and so can’t send any media.
> 
> Of course.  But you could do all the computation necessary for
> generating the ServerHello and accompanying messages (which in TLS 1.3
> is quite a bit).
> 
>> This suggestion might still save half an RTT, though? I’d need to work through a full ladder diagram to figure it out.
> 
> That's the idea.  I haven't plotted it all out either, but I think
> that this is the fastest possible start assuming that you don't send
> any DTLS messages prior to getting a successful connectivity check
> response.

Actually, if the answerer (controlled endpoint) can send on any Valid pair, as in my suggestion, I don’t think you need the ICE role reversal for this optimization.  It can send ClientHello as soon as its first check succeeds, despite never having received any remote checks (with or without USE-CANDIDATE).