Subject: [Ice] Trickle ICE review

From: Peter Thatcher <[email-masked]>
Date: Sun, 26 Mar 2017 03:09:33 +0000

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.

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

- 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".  And then in a WebRTC context, the app might
never signal a candidate (in a client->server use case).  What then?   And
it's not clear to me why this is even useful.   Can we just remove it?  Or
is there something important here?

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

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

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 26 Mar 2017 12:48:46 -0600

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

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.

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

> 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

---

From: Ari Keränen <[email-masked]>
Date: Sun, 26 Mar 2017 20:53:55 +0000

> On 26 Mar 2017, at 13:48, Peter Saint-Andre <[email-masked]> wrote:
[...]
> in the Trickle specification is not limited to interactions between

Agree. Let's add this to ICE-bis. 

I noticed that ICE-bis actually uses this term already, but didn't define it in terminology. Let's fix that.

[...]
> don't want to override any other protocol's rules here).

Sounds good to me.

Thanks,
Ari (chair hat off)

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 26 Mar 2017 15:03:42 -0600

> I noticed that ICE-bis actually uses this term already, but didn't define it in terminology. Let's fix that.

Great. I'll remove it from the Trickle spec.

Peter

---

From: Peter Thatcher <[email-masked]>
Date: Tue, 28 Mar 2017 05:16:56 +0000

> in the Trickle specification is not limited to interactions between
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 doesn't seem critically important to me, but I might be missing

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.

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 28 Mar 2017 10:27:43 -0600

On 3/27/17 11:16 PM, Peter Thatcher wrote:
> 
> 
> On Sun, Mar 26, 2017 at 11:48 AM Peter Saint-Andre <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> 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.
> 

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

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

> And should it be "generate" or "send" a subsequent ICE description?   

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

Peter

---

From: Ari Keränen <[email-masked]>
Date: Tue, 28 Mar 2017 16:43:06 +0000

> On 28 Mar 2017, at 11:27, Peter Saint-Andre <[email-masked]> wrote:
> 

It's used but not defined actually. We'll add this to the terminology of 5245bis.

Cheers,
Ari

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 28 Mar 2017 11:05:23 -0600

> It's used but not defined actually. We'll add this to the terminology of 5245bis.

Right, I think that's the best place for it. Thanks!

Peter

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 28 Mar 2017 18:19:53 +0000

Hi,

I agree that adding a definition of "ICE session" to 5245bis is a good idea.

However, I am not sure simply saying "until a re-start would actually work". You may never do a re-start - often you simply terminate the session.

Also, in RFC 7675 we have the following text:

"That means that a new session, or an ICE restart,..."

...which seems to suggest that a new session and an ICE restart are not related. However, that's probably a minor issue, and we can fix that with an errata if needed.

Regards,

Christer

-----Original Message-----
From: Ice [mailto:[email-masked]] On Behalf Of Ari Keränen
Sent: 28 March 2017 19:43
To: Peter Saint-Andre <[email-masked]>; Peter Thatcher <[email-masked]>
Cc: [email-masked]
Subject: Re: [Ice] Trickle ICE review

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

Cheers,
Ari
_______________________________________________
Ice mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ice

---

From: Peter Thatcher <[email-masked]>
Date: Thu, 30 Mar 2017 01:09:46 +0000

Actually 7675 in the text seems to imply that "new session == ICE restart",
which is exactly "until a restart" means.   You're in one session until you
make a new session by doing an ICE restart.   It seems consistent to me.

On Tue, Mar 28, 2017 at 11:19 AM Christer Holmberg <
[email-masked]> wrote:

> However, I am not sure simply saying "until a re-start would actually
> work". You may never do a re-start - often you simply terminate the session.
>
> ...which seems to suggest that a new session and an ICE restart are not
> related. However, that's probably a minor issue, and we can fix that with
> an errata if needed.
>
> Regards,
>
> Christer
>
>
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 30 Mar 2017 13:19:20 +0000

Hi,

My point is that you can end a session without doing a re-start.

Regards,

Christer

From: Peter Thatcher [mailto:[email-masked]]
Sent: 30 March 2017 04:10
To: Christer Holmberg <[email-masked]>; Ari Keränen <[email-masked]>; Peter Saint-Andre <[email-masked]>
Cc: [email-masked]
Subject: Re: [Ice] Trickle ICE review

Actually 7675 in the text seems to imply that "new session == ICE restart", which is exactly "until a restart" means.   You're in one session until you make a new session by doing an ICE restart.   It seems consistent to me.

On Tue, Mar 28, 2017 at 11:19 AM Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer

-----Original Message-----
From: Ice [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Ari Keränen
Sent: 28 March 2017 19:43
To: Peter Saint-Andre <[email-masked]<mailto:[email-masked]>>; Peter Thatcher <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Ice] Trickle ICE review

> On 28 Mar 2017, at 11:27, Peter Saint-Andre <[email-masked]<mailto:[email-masked]>> wrote:
>

Cheers,
Ari
_______________________________________________
Ice mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ice

---

From: Peter Thatcher <[email-masked]>
Date: Thu, 30 Mar 2017 15:45:54 +0000

Ah, I see what you mean now.

In that case, could we just define "ICE session" as the something like
"stuff until the next ICE restart or the termination of all ICE activity by
this agent"?

On Thu, Mar 30, 2017 at 6:20 AM Christer Holmberg <
[email-masked]> wrote:

> *From:* Peter Thatcher [mailto:[email-masked]]
> *Sent:* 30 March 2017 04:10
> *To:* Christer Holmberg <[email-masked]>; Ari Keränen <
> [email-masked]>; Peter Saint-Andre <[email-masked]>
>
>
> *Cc:* [email-masked]
> *Subject:* Re: [Ice] Trickle ICE review
>
>
>
> Actually 7675 in the text seems to imply that "new session == ICE
> restart", which is exactly "until a restart" means.   You're in one session
> until you make a new session by doing an ICE restart.   It seems consistent
> to me.
>
>
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 30 Mar 2017 11:41:34 -0600

On 3/30/17 9:45 AM, Peter Thatcher wrote:
> "stuff until the next ICE restart or the termination of all ICE activity
> by this agent"? 

Right, there's no "ICE session termination" message, so that'll have to do.

Peter

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 30 Mar 2017 17:53:31 +0000

Hi,

Perhaps we could say something like "re-start or once all candidates have been released", or something like that... We seem to agree, so it's just about wording :)

Regards,

Christer

-----Original Message-----
From: Peter Saint-Andre [mailto:[email-masked]] 
Sent: 30 March 2017 20:42
To: Peter Thatcher <[email-masked]>; Christer Holmberg <[email-masked]>; Ari Keränen <[email-masked]>
Cc: [email-masked]
Subject: Re: [Ice] Trickle ICE review

On 3/30/17 9:45 AM, Peter Thatcher wrote:
> "stuff until the next ICE restart or the termination of all ICE 
> activity by this agent"?

Peter

---

From: Taylor Brandstetter <[email-masked]>
Date: Thu, 30 Mar 2017 20:45:00 -0700

>
> In the phrase " A Trickle ICE agent MUST NOT pair a local candidate until
> mean?

Sorry I'm late at responding to this, but I assumed the main intention here
was that candidates are paired in the same order that they're trickled,
because that was necessary for the unfreezing logic to work. For example:
suppose an endpoint already has remote candidates, and then gathers RTP and
RTCP candidates. It pairs them in the order "RTCP, RTP" (maybe the STUN
response for the RTCP candidate came back first), resulting in an RTCP pair
being unfrozen first, but they're trickled in the order "RTP, RTCP" (as a
result of the restrictions of section 16), resulting in the remote endpoint
unfreezing the RTP pair first.

Before, this would have resulted in things failing (as I recall). But this
isn't as much of a problem now; I'm looking at the current section 8.1.1,
and it would result in the local endpoint just unfreezing *both* pairs, so
things would be able to proceed.

But it still could result in extra pairs being unfrozen; is that
acceptable? If not, I'd suggest moving this note to section 16, and making
it more clear what the intention is. For example: "Candidates MUST be
paired, following the procedures in section 8.1.1, in the same order that
they're trickled."

An important related question: There used to be a line that said "When
trickle updates are sent, each candidate MUST be delivered to the receiving
Trickle ICE implementation ... in the same order that they were sent." But
the "in the same order that they were sent" part has been removed. Do we no
longer require that the signaling mechanism preserves ordering? If so,
Section 16 doesn't make sense any more; it requires a specific order of
candidate trickling, but that can't be guaranteed if the signaling
mechanism doesn't preserve ordering. All my ramblings above would be moot
as well.

On Thu, Mar 30, 2017 at 10:53 AM, Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
> Perhaps we could say something like "re-start or once all candidates have
> been released", or something like that... We seem to agree, so it's just
> about wording :)
>
> Regards,
>
> Christer
>
> To: Peter Thatcher <[email-masked]>; Christer Holmberg <
> [email-masked]>; Ari Keränen <[email-masked]>
> Cc: [email-masked]

---

From: Peter Thatcher <[email-masked]>
Date: Fri, 31 Mar 2017 22:03:23 +0000

Ah, thanks for explaining this.  I like your idea of making the real
intention explicit (pair and trickle in the same order).  I think that's
much more clear and precise.

On Thu, Mar 30, 2017 at 8:45 PM Taylor Brandstetter <[email-masked]>
wrote:

Hi,

Regards,

Christer

-----Original Message-----
From: Peter Saint-Andre [mailto:[email-masked]]
Sent: 30 March 2017 20:42
To: Peter Thatcher <[email-masked]>; Christer Holmberg <

Peter