Re: [MMUSIC] Trickle ICE

Emil Ivov <emcho@jitsi.org> Wed, 10 October 2012 22:46 UTC

Return-Path: <emil@sip-communicator.org>
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 0380911E808D for <mmusic@ietfa.amsl.com>; Wed, 10 Oct 2012 15:46:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 E11Lq0XOOf+7 for <mmusic@ietfa.amsl.com>; Wed, 10 Oct 2012 15:46:33 -0700 (PDT)
Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id C3C1D21F854F for <mmusic@ietf.org>; Wed, 10 Oct 2012 15:46:32 -0700 (PDT)
Received: by mail-we0-f172.google.com with SMTP id u46so723840wey.31 for <mmusic@ietf.org>; Wed, 10 Oct 2012 15:46:31 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=yAfP+aYBqjG0jf+iJnDPhpK3ebYja1gymGUBZQNSx+Q=; b=M0KFubcIJgovVLxwd+FGoSe+tTOZYVDXA/slwjpFOZmbx3IHY0CGa6PQSpjhVxmthS bY0Z9Tgx1ghHy1GKOkTGaUzKXl65RgV0E8JsoIFQJ3JQr0bFNInJr2h6ZazXBR9ioPoU A90ZmXHTrNEVfjom+151hR5A5+A1d+HEo72nyu5apcXmQBAlxiD4GZELeBa6p0iMEr/O DpsFvRFbJIw1VikrrfK99h4JR1UKL5hue/+JGrLPjzUYWXqDtzdfoo27DSbtd0x5h2FB B0ZUTreHC17xYDQDC0SbqS87ZkJtuCx3SzmkrUpm0LOkO3Coq3l/Yu2KJ0YkIbQhslz+ HiQg==
Received: by 10.180.84.41 with SMTP id v9mr16155842wiy.8.1349909191560; Wed, 10 Oct 2012 15:46:31 -0700 (PDT)
Received: from camionet.local ([2a01:e35:8a55:abc0:df4:37b5:8b8b:5b6]) by mx.google.com with ESMTPS id q7sm5253342wiy.11.2012.10.10.15.46.28 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 10 Oct 2012 15:46:29 -0700 (PDT)
Message-ID: <5075FAC3.20709@jitsi.org>
Date: Thu, 11 Oct 2012 00:46:27 +0200
From: Emil Ivov <emcho@jitsi.org>
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: Martin Thomson <martin.thomson@gmail.com>
References: <20121010141600.30314.22528.idtracker@ietfa.amsl.com> <5075864F.3030700@jitsi.org> <CABkgnnX1TaXMYqqLzvwzMRjPO72CccUj6j7oic_-6Oqy+pUZrg@mail.gmail.com>
In-Reply-To: <CABkgnnX1TaXMYqqLzvwzMRjPO72CccUj6j7oic_-6Oqy+pUZrg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQnz8RNc+ntM44Qc4p2ynqYqienp3h9rixHY4Jr0rMJHat2rLI2qNYHkl4mJhAUhi3v6ynUR
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 22:46:34 -0000

Hey Martin,

On 10.10.12, 18:03, Martin Thomson wrote:
> 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 

Quite likely, yes.

> (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.

Yes, the above sentence may indeed be misleadingly read as "respecting
the order of the streams is all there is to it". What was really meant
was something along the lines of: "respecting the order of streams
improves the chances of the connectivity checks being run simultaneously
for a particular stream/component"

> 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."

Correct, but this is not going to be a problem. When the corresponding
candidates eventually find their way to the agent, it would unfreeze
their local counter-parts and, if necessary, rerun any in-progress or
failed checks. This is explained in Section 9:

   [snip] the agent examines the check
   list looking for another pair that would be redundant with the new
   one.  If such a pair exists and its state is:

   Failed:   the agent chooses the pair with the higher priority local
      candidate, places it in the Waiting state and removes the other
      one as redundant.
   In-Progress:   The agent cancels the in-progress transaction (where
      cancellation happens as explained in Section 7.2.1.4 of
      [RFC5245]), then it chooses the pair with the higher priority
      local candidate, places it in the Waiting state and removes the
      other one as redundant.

Does this sound reasonable or were you referring to something else?

> Several points in the draft presume that this will be made "MUST
> implement" for WebRTC. That assumption is not stated, though
> it should be. 

Mmm ... it might be my lack of IETF experience, but aren't references
supposed to happen the other way around? That is, if RTCWEB decides to
use Trickle ICE, then shouldn't RTCWEB documents be referring to this
spec and making whatever normative declarations they find appropriate?

Besides, trickle ICE is already in use by XMPP apps and SIP will
probably follow. Why would the RTCWEB usage be referred to and not the
others?

> 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).

Well the idea is that it doesn't really need to be signalling. The
example that we give is about a WebRTC app with no cross domain support.
In this case the WebRTC app can just enable trickle ICE without checking
anything since the remote agent is bound to have it too. Again, it's
just an example. We are not saying this is how it's going to be done for
RTCWEB.

Does this make sense?

Emil

> --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
> 

-- 
Emil Ivov, Ph.D.                       67000 Strasbourg,
Project Lead                           France
Jitsi
emcho@jitsi.org                        PHONE: +33.1.77.62.43.30
https://jitsi.org                      FAX:   +33.1.77.62.47.31