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

Martin,  
  Just to make sure that I understand your position, I take you to be
saying:  
1) in the case where both endpoints have downloaded their apps from the
same server, they can do trickle ICE any way that they want.
2) in the case where an application is  talking to an unknown or legacy
peer, trickle  ICE is a bad idea because there is no standard way to do
it. (i.e. try it at your own risk)

Is this correct?

- Jim 

-----Original Message-----
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf
Of Martin Thomson
Sent: Friday, August 24, 2012 5:23 PM
To: Cullen Jennings
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Filling in details on "trickle ICE"

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
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb