Re: [Ice] Trickle ICE review

Taylor Brandstetter <deadbeef@google.com> Fri, 31 March 2017 03:45 UTC

Return-Path: <deadbeef@google.com>
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC44112975C for <ice@ietfa.amsl.com>; Thu, 30 Mar 2017 20:45:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 FWDNzplxZ8t9 for <ice@ietfa.amsl.com>; Thu, 30 Mar 2017 20:45:03 -0700 (PDT)
Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F37412978B for <ice@ietf.org>; Thu, 30 Mar 2017 20:45:01 -0700 (PDT)
Received: by mail-qt0-x229.google.com with SMTP id x35so55813005qtc.2 for <ice@ietf.org>; Thu, 30 Mar 2017 20:45:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XcglaDJLi8EY2aEZ2LXS9LkEz7JRzExWlMS8RErvSXs=; b=RGBqGOwULTZqdKxjivFWAB54tssrid6peyoUVM5KIiAvM/dYP0qilP+AEzYwDKSpif eOhj5/0J5k4fPy9dRn1dx3lAokwl1eaqVKRIwlzpQgLhsR7ciAX42QzYaCBmW8ffILmh Hz0bSBQjW0XrjVefecz0sZeccun6xaGprRwfeg3IwicTlmlhZK6/iHX836aKlFWingro VeTAxUaoVW9Rd4UE5ztIFCxNhTTfuqza90eDVSmw69HH3MOGSV2LsffZruqiEVo3yI7L sK6pbiGHdVAYiRJBTB2ZDpZKV+c5ADSZYrgCTEsJd4OqmGzFa5PK1tAHwHHejPK2zQQe Zu+g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XcglaDJLi8EY2aEZ2LXS9LkEz7JRzExWlMS8RErvSXs=; b=kpOCb46fTSPYA6Enlvzw+lkXFm/m5Aw3xNZx3pLSWOwatbNZm/YkE/6x9AOMmmE8de SAQCwpkrqEL8XF8pAsaAEQOkpxwwwNJpnbXtMKzCiQjZGM0lZ1zJlOnjpgPkAB1KfTEq JILdt08gfMoa5k6lBGIXzMQFKsSt4SesYSM5PJTrDfkUuvy4VvN5CeYGSZyeRAptTvN0 6wdnuACafRLbjEIKAU1y5AN4iZ/vTDSeSffhLW2BUeuOEB04mpTzm+BKlpbrm7X1DEYQ epUrtIN5Znwex0eZeo4QLS0PE8gjKTuJSgGZIhU+Q+dHjLOJ2qajrsP83eSLBwDni5PR nHsA==
X-Gm-Message-State: AFeK/H2Z2JpAXkZjBCvmP38F83cxSAZhVz6rfITJXkOmzaD28NZDiRdCr8PX6mi3ndH4tS8NR4C1OgbwprjLmXIo
X-Received: by 10.237.41.7 with SMTP id s7mr740644qtd.64.1490931900601; Thu, 30 Mar 2017 20:45:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.12.154.209 with HTTP; Thu, 30 Mar 2017 20:45:00 -0700 (PDT)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CB38EBB@ESESSMB109.ericsson.se>
References: <CAJrXDUHzNT3v5oMPBQu5_OsXwonY7cogDQgTt5QPxN0=6DWQkQ@mail.gmail.com> <7ebb3254-a882-6e05-3159-0ec56614831b@stpeter.im> <CAJrXDUEi0n7P5mDuuLGj285AmQqr9HDFUPGLtLnU+BuJpws6Tw@mail.gmail.com> <7e9e8188-2add-0497-e94f-14ee41afe02d@stpeter.im> <BFB0CDEF-4572-41D5-A5D2-A5D210A1E175@ericsson.com> <7594FB04B1934943A5C02806D1A2204B4CB330A0@ESESSMB109.ericsson.se> <CAJrXDUGy2VUKe33vLm-QOrQ+OSV+nFCKTsHXPt_VZ8sqrdpX0Q@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B4CB378CD@ESESSMB109.ericsson.se> <CAJrXDUFBO9Q4aHMjMr-0L505BMWPNSPkZ+sPGSNGu-JAXz2qww@mail.gmail.com> <0308af65-2cc9-c793-946d-6157d71db069@stpeter.im> <7594FB04B1934943A5C02806D1A2204B4CB38EBB@ESESSMB109.ericsson.se>
From: Taylor Brandstetter <deadbeef@google.com>
Date: Thu, 30 Mar 2017 20:45:00 -0700
Message-ID: <CAK35n0ZXaq0vj0xC0fS0fTKLFq+bogfwpr9-nwtXvztW+g7jYQ@mail.gmail.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: Peter Saint-Andre <stpeter@stpeter.im>, Peter Thatcher <pthatcher@google.com>, Ari Keränen <ari.keranen@ericsson.com>, "ice@ietf.org" <ice@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c06b00c52386a054bfea2fb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ice/95SvCvYnJrEIQlSPin82PK6A9eQ>
Subject: Re: [Ice] Trickle ICE review
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" <ice.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ice>, <mailto:ice-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ice/>
List-Post: <mailto:ice@ietf.org>
List-Help: <mailto:ice-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ice>, <mailto:ice-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 Mar 2017 03:45:07 -0000

>
> In the phrase " A Trickle ICE agent MUST NOT pair a local candidate until
> it has been trickled to the remote agent.", what does "has been trickled"
> mean?


Sorry I'm late at responding to this, but I assumed the main intention here
was that candidates are paired in the same order that they're trickled,
because that was necessary for the unfreezing logic to work. For example:
suppose an endpoint already has remote candidates, and then gathers RTP and
RTCP candidates. It pairs them in the order "RTCP, RTP" (maybe the STUN
response for the RTCP candidate came back first), resulting in an RTCP pair
being unfrozen first, but they're trickled in the order "RTP, RTCP" (as a
result of the restrictions of section 16), resulting in the remote endpoint
unfreezing the RTP pair first.

Before, this would have resulted in things failing (as I recall). But this
isn't as much of a problem now; I'm looking at the current section 8.1.1,
and it would result in the local endpoint just unfreezing *both* pairs, so
things would be able to proceed.

But it still could result in extra pairs being unfrozen; is that
acceptable? If not, I'd suggest moving this note to section 16, and making
it more clear what the intention is. For example: "Candidates MUST be
paired, following the procedures in section 8.1.1, in the same order that
they're trickled."

An important related question: There used to be a line that said "When
trickle updates are sent, each candidate MUST be delivered to the receiving
Trickle ICE implementation ... in the same order that they were sent." But
the "in the same order that they were sent" part has been removed. Do we no
longer require that the signaling mechanism preserves ordering? If so,
Section 16 doesn't make sense any more; it requires a specific order of
candidate trickling, but that can't be guaranteed if the signaling
mechanism doesn't preserve ordering. All my ramblings above would be moot
as well.

On Thu, Mar 30, 2017 at 10:53 AM, Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> Hi,
>
> Perhaps we could say something like "re-start or once all candidates have
> been released", or something like that... We seem to agree, so it's just
> about wording :)
>
> Regards,
>
> Christer
>
> -----Original Message-----
> From: Peter Saint-Andre [mailto:stpeter@stpeter.im]
> Sent: 30 March 2017 20:42
> To: Peter Thatcher <pthatcher@google.com>; Christer Holmberg <
> christer.holmberg@ericsson.com>; Ari Keränen <ari.keranen@ericsson.com>
> Cc: ice@ietf.org
> Subject: Re: [Ice] Trickle ICE review
>
> On 3/30/17 9:45 AM, Peter Thatcher wrote:
> > Ah, I see what you mean now.
> >
> > In that case, could we just define "ICE session" as the something like
> > "stuff until the next ICE restart or the termination of all ICE
> > activity by this agent"?
>
> Right, there's no "ICE session termination" message, so that'll have to do.
>
> Peter
>
> _______________________________________________
> Ice mailing list
> Ice@ietf.org
> https://www.ietf.org/mailman/listinfo/ice
>