Re: [MMUSIC] Trickle ICE

Martin Thomson <martin.thomson@gmail.com> Wed, 10 October 2012 16:03 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D99621F8681 for <mmusic@ietfa.amsl.com>; Wed, 10 Oct 2012 09:03:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.862
X-Spam-Level:
X-Spam-Status: No, score=-3.862 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTB-+1PddTBx for <mmusic@ietfa.amsl.com>; Wed, 10 Oct 2012 09:03:03 -0700 (PDT)
Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 4645C21F8607 for <mmusic@ietf.org>; Wed, 10 Oct 2012 09:03:03 -0700 (PDT)
Received: by mail-wi0-f178.google.com with SMTP id hr7so751813wib.13 for <mmusic@ietf.org>; Wed, 10 Oct 2012 09:03:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3L4JL13ChDwKxeLl4k0oL5WeEhMcQ0tVBWLM043+7XM=; b=aWcaMDCEfS0GUDiIGdftglmkJSDzXjwVrKaVQ86ckfhCaUsXbxjsFmHgRrYO38d0f+ XWqCMsdU1vN9JVIJr6uCIGXhCAh1OAKmZs59W3k1mcS/bpPYTvfa9KLJ6afOVgzkNnaQ yXpcBfOdxBX6XdTwh4zyZLeag6Ss5C9Y3wQZrnfOd8h5jA7pne6SPvjj3OlJfUoQb/rF 8SR8/02Z5U5xelszpxYVVMlbC6D9+cMMDwiI4nS0Gh1jvqnDiVCTauMY867fV3+2PP1E fxabHWYpXstbxl5f4RePdbaR0n0LZZgb74I2oAz1t9rBIsd4KyJqJPFuzr3sQ94PHLHD ERuw==
MIME-Version: 1.0
Received: by 10.216.141.16 with SMTP id f16mr15734250wej.130.1349884982292; Wed, 10 Oct 2012 09:03:02 -0700 (PDT)
Received: by 10.180.96.9 with HTTP; Wed, 10 Oct 2012 09:03:02 -0700 (PDT)
In-Reply-To: <5075864F.3030700@jitsi.org>
References: <20121010141600.30314.22528.idtracker@ietfa.amsl.com> <5075864F.3030700@jitsi.org>
Date: Wed, 10 Oct 2012 09:03:02 -0700
Message-ID: <CABkgnnX1TaXMYqqLzvwzMRjPO72CccUj6j7oic_-6Oqy+pUZrg@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Emil Ivov <emcho@jitsi.org>
Content-Type: text/plain; charset="UTF-8"
Cc: MMUSIC IETF WG <mmusic@ietf.org>
Subject: Re: [MMUSIC] Trickle ICE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
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, 10 Oct 2012 16:03:04 -0000

I haven't had a lot of time to think about this, but here are some
early comments:

It seems to me that the guidance in Section 6.2 regarding the
unfreezing of check lists needs a little more thought (and
specification).  The goals are clear: "so that checks for the same
media stream [component] would be performed simultaneously by both
agents".  The process by which each peer arrives at this point is less
so.

A naive implementation would use the set of known candidates on each
component to make this determination.  However, that set is
potentially different to the set of candidates known to their peer.
That could cause a mismatch if both peers "unfreeze the first
non-empty checklist."

Several points in the draft presume that this will be made "MUST
implement" for WebRTC.  That assumption is not stated, though it
should be.  In particular, this relates to the decision to require
signaling of support for trickle ICE outside of SDP (a decision that I
need to think about a little more).

--Martin

On 10 October 2012 07:29, Emil Ivov <emcho@jitsi.org> wrote:
> Hey all,
>
> Eric, Justin and I have just submitted a first version of the
> specification of a mechanism for incremental provisioning of ICE
> candidates, also known as "Trickle ICE".
>
> The spec is in an early state and will undoubtedly see a lot of changes
> as implementations progress. It does however describe the main idea so
> comments and questions are most welcome!
>
> Cheers,
> Emil
>
>
> -------- Original Message --------
> Subject: New Version Notification for
> draft-rescorla-mmusic-ice-trickle-00.txt
> Date: Wed, 10 Oct 2012 07:16:00 -0700
> From: internet-drafts@ietf.org
> To: emcho@jitsi.org
> CC: justin@uberti.name, ekr@rtfm.com
>
>
> A new version of I-D, draft-rescorla-mmusic-ice-trickle-00.txt
> has been successfully submitted by Emil Ivov and posted to the
> IETF repository.
>
> Filename:        draft-rescorla-mmusic-ice-trickle
> Revision:        00
> Title:           Trickle ICE: Incremental Provisioning of Candidates for the
> Interactive Connectivity Establishment (ICE) Protocol
> Creation date:   2012-10-10
> WG ID:           Individual Submission
> Number of pages: 14
> URL:
> http://www.ietf.org/internet-drafts/draft-rescorla-mmusic-ice-trickle-00.txt
> Status:
> http://datatracker.ietf.org/doc/draft-rescorla-mmusic-ice-trickle
> Htmlized:
> http://tools.ietf.org/html/draft-rescorla-mmusic-ice-trickle-00
>
>
> Abstract:
>    This document describes an extension to the Interactive Connectivity
>    Establishment (ICE) protocol that allows ICE agents to send and
>    receive candidates incrementally rather than exchanging complete
>    lists.  With such incremental provisioning, ICE agents can begin
>    connectivity checks while they are still gathering candidates and
>    considerably shorten the time necessary for ICE processing to
>    complete.
>
>    The above mechanism is also referred to as "trickle ICE".
>
>
>
>
>
> The IETF Secretariat
>
>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic