Re: [Ice] Trickle ICE review

[Peter Saint-Andre <[e-mail]>]

On 3/25/17 9:09 PM, Peter Thatcher wrote:
> Ari and I reviewed the latest Trickle ICE draft in preparation for going
> to WGLC and found a few more things worth considering fixing:
> 
> - Some minor editorial issues that have separately been sent to the authors.

Received.

> - The name "ICE negotiation session" with definition of "A virtual
> session ..." is confusing.   I understand that we need a word for
> "period between restarts" and "period across restarts".  But what does
> "virtual" mean in this context?  And what does "negotiation" mean in
> "ICE negotiation session"?  Here's a possible suggestion: call it
> "single-exchange session".   A single-exchange session is the period
> from a single exchange of ICE description until the next exchange.  A
> "normal" ICE session is basically a multi-exchange session.

This might be clearer:

   ICE Session:  All of the ICE-related interactions between ICE agents
      up until an ICE restart (if any).

However, that definition probably belongs in 5245bis. The term as used
in the Trickle specification is not limited to interactions between
Trickle ICE agents.

> - In the phrase " A Trickle ICE agent MUST NOT pair a local candidate
> until it has been trickled to the remote agent.", what does "has been
> trickled" mean?  That it's been sent on the network?  When it's been
> acked by the remote side?  When it is in queue such that it will later
> be put on the network?  It seems really hard to pin down an appropriate
> time when something "has been trickled". 

In the interest of startup time, I'd say that a candidate has been
trickled when it has been sent. Waiting for acks might slow things down.

> And then in a WebRTC context,
> the app might never signal a candidate (in a client->server use case). 
> What then?  

I don't think we had considered that case.

> And it's not clear to me why this is even useful.   Can we
> just remove it?  Or is there something important here?

It doesn't seem critically important to me, but I might be missing
something.

> - The paragraph "Note: So that both agents will have the same view of
> candidate priorities, it is important to replacing existing pairs with
> seemingly equivalent higher-priority ones and to always update
> peer-reflexive candidates if equivalent alternatives are received
> through signaling." seems duplicate with other parts in the doc.  Do we
> even need this paragraph?

You're right, these guidelines are indeed mentioned elsewhere. Let's
remove them here.

> - "Either agent MAY generate a subsequent ICE description at any time
> allowed by RFC3264".  This causes ICE to be dependent on SDP, which we
> were trying to avoid.  Was this just one place where we missed removing
> a dependency on SDP?  I would suggest removing it or replacing it with
> the phrase "Either agent MAY generate subsequent ICE descriptions at any
> time", unless there is a clear time when an ICE agent cannot (and I
> can't think of one). 

This seems to be a stray mention of RFC 3264 that was not removed in
earlier editing. Perhaps "Either agent MAY generate a subsequent ICE
description at any time allowed by the signaling protocol in use" (we
don't want to override any other protocol's rules here).

> As soon as these are resolved, we believe we can go to WGLC.

Great. Thanks for the review.

Peter