Re: [rtcweb] Filling in details on "trickle ICE"

Martin Thomson <martin.thomson@gmail.com> Fri, 24 August 2012 21:22 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF1E21F8499 for <rtcweb@ietfa.amsl.com>; Fri, 24 Aug 2012 14:22:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.91
X-Spam-Level:
X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[AWL=-0.311, 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 TkKQq8IEhEsE for <rtcweb@ietfa.amsl.com>; Fri, 24 Aug 2012 14:22:42 -0700 (PDT)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5772021F8496 for <rtcweb@ietf.org>; Fri, 24 Aug 2012 14:22:42 -0700 (PDT)
Received: by lbky2 with SMTP id y2so659023lbk.31 for <rtcweb@ietf.org>; Fri, 24 Aug 2012 14:22:41 -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=3Ldw0lE2v8FgLUhwvkiefAGGxglQwYWLYKx7kxqRqUE=; b=vvLcycYQvqf/rEoriuyl1s+EVkpBVb54UvQ1d/IJ92pZkeB9InvtRtBYPypnuzit8g LpTBNSRKx1yKlD8KRp9yVFiK34se40xAj2EOLahTGz9qu6XAdKY5p5rafzb3rdw9PYtY hGNyt6erL+HVJO4oMBeXB5f6vnjU2DEueb1HTzwb5VhBTFhAwQUs1tdfQuzEtRsSbret 0tdW6N8V3IHMLUX19W1laDdlWpYmE7tx+5Yqp5cQsU4PeB7KtXxtDx+G0zZ4kq/BuPOW mTeVmg9O1hOkQr2sAp+WKrJRwR2PhbHm0N8yQP29amONUQJ8PohJrb+2FALtsz0sy0sj l72w==
MIME-Version: 1.0
Received: by 10.152.124.76 with SMTP id mg12mr7158880lab.10.1345843361188; Fri, 24 Aug 2012 14:22:41 -0700 (PDT)
Received: by 10.112.41.193 with HTTP; Fri, 24 Aug 2012 14:22:41 -0700 (PDT)
In-Reply-To: <3B8DB12B-ABB3-4AC2-A0A0-93DC62C619D3@iii.ca>
References: <CABcZeBMzgAs=hK38hCjS7t6yLjkTydS2TQUb8R3rBbRKGakVdQ@mail.gmail.com> <CABkgnnVBBAH=HCkn_cksBs_9A_hm=VfFwcTtvOM3C7XB2h2KTA@mail.gmail.com> <CABcZeBMFUFjU=FQo5LeJrcMfajeae0j+PWw5U2g5dUQNcJLWaA@mail.gmail.com> <CABkgnnXiL3_U+Hci9ooDqBCsoV3KF8pwgcf9zbuN6EKZkK+aiQ@mail.gmail.com> <CABcZeBNkkH93ybuMWoFg-ddKWnRgdn2Vgyb50W21A2GoMWxw6Q@mail.gmail.com> <CABkgnnXQ25ZYNqeO+=FsYDR3aNvFS2zvrKWGs5o=h8m+Eq=Y+Q@mail.gmail.com> <3B8DB12B-ABB3-4AC2-A0A0-93DC62C619D3@iii.ca>
Date: Fri, 24 Aug 2012 14:22:41 -0700
Message-ID: <CABkgnnU3ecmhUwCYHmppwLJz-nbSA6=VRF7nF7wcpb+5QAWmdQ@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Cullen Jennings <fluffy@iii.ca>
Content-Type: text/plain; charset=UTF-8
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Filling in details on "trickle ICE"
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Aug 2012 21:22:43 -0000

On 24 August 2012 11:16, Cullen Jennings <fluffy@iii.ca> wrote:
>
> I'm confused on what you are trying to say. Are you saying
>
> 1) we don't need trickle ICE
>
> 2) we can do trickily ICE but no standards need to be written for two different devices to do trickle ICE

It's just 2)

Trickle candidates is a *new thing*, a new problem that needs to be
solved.  It's fairly clear that trickling is an optimization that was
never considered in the design of ICE.

We can solve the problem by writing an RFC, but you can also write
fewer standards and enable the same outcome.

An RFC would specify how this differs from ICE and what new behaviours
are expected from endpoints.  That RFC would also describe how
implementations would discover if peers support the new behaviour so
that they don't do things that would surprise or break implementations
that did not.


The alternative is to recognize that ICE specifies a number of
features that are really, really important, both from an
interoperability and a security standpoint:
  The use of STUN Binding requests to gather server reflexive addresses.
  The use of TURN to allocate TURN relays.
  The use of STUN Binding requests to establish connectivity and consent.
  Constraints over how checks can be sent (which are actually not all
suitable in this context for other reasons).
  A way to resolve the problem of who performs candidate pair selection.

Then ICE has a bunch of really useful advice on what implementations
might do: gather candidates, prioritize them, check them, retry
checks, track those that succeed, etc...  None of that is really
necessary, just super handy.

The signalling stuff in ICE is not relevant to the rtcweb
architecture.  So we can ignore that part.  WebRTC decided to use it,
but that's their problem.

The most invasive thing that ICE does is describe a specific algorithm
in some detail.  Implicit in this algorithm is the fact that all
candidates have to be signaled together.  This is also stuff that we
don't *need* in rtcweb.

This might have been useful when you use RFCs to describe every facet
of your application, but it is in fact unnecessary for applications of
the sort that exist in rtcweb.  Many of these applications want things
like trickle candidates, which can give better session initialization
performance.  Many of these will have code on both endpoints.

Obviously, applications that want to interoperate with ICE
implementations will have to play nice with ICE.  But this is usually
known a priori.  Building signaling for this is presumptuous.

I understand how someone might conclude that you need to standardize
this behaviour.  It depends on what preconceptions you have.  If you
wanted to port trickle candidates to your SIP PBX, then I can see how
the standardization option might seem attractive.

The Microsoft API proposal makes all of this possible by only taking
the really important stuff from RFC 5245.

--Martin