Re: [Ice] Trickle ICE review

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

On 3/27/17 11:16 PM, Peter Thatcher wrote:
> 
> 
> On Sun, Mar 26, 2017 at 11:48 AM Peter Saint-Andre <[e-mail]
> <mailto:[e-mail]>> wrote:
> 
>     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.
> 
> 
> I like that idea of using "ICE session" to mean the thing between
> restarts as long as it's compatible with 5245 and 5245bis and it doesn't
> cause confusion such that people think an "ICE session" is the time
> period across all ICE restarts.
> 
> I originally thought it should go in 5245bis also, but Ari thought it
> didn't make sense there since it would never use the term after defining
> it.  

It's already used in 5245bis, isn't it? But we can continue to define it
in Trickle.

>     > - 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.
> 
> 
> I think there's still the issue of what does "sent" mean?  In the
> network buffer of the OS kernel ready to go out?  In a queue on a
> "network thread" that's going to give it to the OS kernel to go out?  
> Does it actually have to be on the network or just queued to be so later?  
> 
> If we don't need it, I'd say we just remove it.  Doubly so if we can't
> even be sure what it means.

I'd say let's cut it.

>     > - 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).
> 
> 
> Deferring to the signaling protocol sounds like a good idea.
> 
> And should it be "generate" or "send" a subsequent ICE description?   

I thought we didn't know the meaning of send. :-)

Peter