Re: [Ice] Trickle ICE review

[Peter Thatcher <[e-mail]>]

On Sun, Mar 26, 2017 at 11:48 AM Peter Saint-Andre <[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.


> > - 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.


>
> > - 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?


> > As soon as these are resolved, we believe we can go to WGLC.
>
> Great. Thanks for the review.
>
> Peter
>
>