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

[Martin Thomson <[e-mail]>]

On 24 August 2012 11:16, Cullen Jennings <[e-mail]> 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