Subject: [Ice] Some thoughts on trickling the ufrag

From: Peter Thatcher <[email-masked]>
Date: Thu, 17 Mar 2016 22:20:35 -0700

(As an individual, not a chair)

Earlier, we had some discussion around adding the ufrag to the trickled
candidate so that when one receives the a trickled candidate after an ICE
restart, it's clear if the candidate applies to the ICE ufrag/pwd from
before or after the ICE restart.

I have a few thoughts/questions about this:

1.  We saw applications where this was a real-world issue.

2.  We implemented the addition of the ufrag to candidates in Chrome, and
it fixed the issues observed.  Further, it was a very easy fix.

3.  Do we have consensus in the group that we should standardize this
solution?

4.  If so, should we simply add it to the trickle-ice draft?  Or should it
be a separate draft?

Thanks,
Peter

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 20 Mar 2016 11:17:20 +0000

Hi,

What reason would there be for putting it in a separate draft?

Regards,

Christer

From: Ice [mailto:[email-masked]] On Behalf Of Peter Thatcher
Sent: 18 March 2016 07:21
To: [email-masked]
Subject: [Ice] Some thoughts on trickling the ufrag

Earlier, we had some discussion around adding the ufrag to the trickled candidate so that when one receives the a trickled candidate after an ICE restart, it's clear if the candidate applies to the ICE ufrag/pwd from before or after the ICE restart.

2.  We implemented the addition of the ufrag to candidates in Chrome, and it fixed the issues observed.  Further, it was a very easy fix.

3.  Do we have consensus in the group that we should standardize this solution?

4.  If so, should we simply add it to the trickle-ice draft?  Or should it be a separate draft?

Thanks,
Peter

---

From: Emil Ivov <[email-masked]>
Date: Sun, 20 Mar 2016 06:25:42 -0500

Well because it's a signaling issue. IIRC it is something that we agreed
trickle ice for sip would
Include.

I guess it's more of a question if and how it should be in trickle ice for
sip.

The tricky part there is that this is a purely signalling issue and trickle
ice is meant to be signalling agnostic. A headsup to implementors may
therefore be more appropriate.
Emil

On Sunday, 20 March 2016, Christer Holmberg <[email-masked]>
wrote:

> *From:* Ice [mailto:[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>] *On Behalf Of *Peter
> Thatcher
> *Sent:* 18 March 2016 07:21
> *To:* [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
> *Subject:* [Ice] Some thoughts on trickling the ufrag
>
>
>

-- 
sent from my mobile

---

From: Peter Thatcher <[email-masked]>
Date: Mon, 21 Mar 2016 10:36:21 -0700

Would it make sense to have a "SHOULD signal ufrag on a trickled candidate"?

On Sun, Mar 20, 2016 at 4:25 AM, Emil Ivov <[email-masked]> wrote:

> The tricky part there is that this is a purely signalling issue and
> trickle ice is meant to be signalling agnostic. A headsup to implementors
> may therefore be more appropriate.
> Emil
>
> On Sunday, 20 March 2016, Christer Holmberg <
> [email-masked]> wrote:
>
>> Hi,
>>
>>
>>
>> *From:* Ice [mailto:[email-masked]] *On Behalf Of *Peter Thatcher
>> *To:* [email-masked]

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 21 Mar 2016 18:09:34 +0000

Hi,

Is there a reason for not having MUST?

Regards,

Christer

From: Peter Thatcher [mailto:[email-masked]]
Sent: 21 March 2016 19:36
To: Emil Ivov <[email-masked]>
Cc: Christer Holmberg <[email-masked]>; [email-masked]
Subject: Re: [Ice] Some thoughts on trickling the ufrag

On Sun, Mar 20, 2016 at 4:25 AM, Emil Ivov <[email-masked]<mailto:[email-masked]>> wrote:
Well because it's a signaling issue. IIRC it is something that we agreed trickle ice for sip would
Include.

I guess it's more of a question if and how it should be in trickle ice for sip.

The tricky part there is that this is a purely signalling issue and trickle ice is meant to be signalling agnostic. A headsup to implementors may therefore be more appropriate.
Emil

On Sunday, 20 March 2016, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer

From: Ice [mailto:[email-masked]] On Behalf Of Peter Thatcher
Sent: 18 March 2016 07:21
To: [email-masked]<mailto:[email-masked]>
Subject: [Ice] Some thoughts on trickling the ufrag

Thanks,
Peter

--
sent from my mobile

---

From: Emil Ivov <[email-masked]>
Date: Wed, 30 Mar 2016 17:20:42 -0500

My concern is that Trickle ICE is supposed to be signalling agnostic.

The whole part with the a= lines was only meant to be a convenience but 
addressing over the wire issues are supposed to be handled by other 
specs like Trickle ICE for SIP.

Whether or not the generation needs to be signalled depends entirely on 
the transport.

SIP for example does allow for out of order messages so it absolutely 
needs it and that's why that draft says:

    All INFO requests MUST carry the "a=ice-pwd:" and "a=ice-ufrag:"
    attributes that would allow mapping them to a specific ICE
    generation.

A WebRTC browser, when signalling candidates through the API does NOT 
need that at all because it can guarantee that candidates it trickles 
will be mappable to an SLD/SRD round.

So, as I said, a recommendation for extending specs and implementors 
sounds like the best path here. Normative language sounds like going out 
of scope for this draft.

Emil

On 21.03.16 г. 13:09, Christer Holmberg wrote:
> *From:*Peter Thatcher [mailto:[email-masked]]
> *Sent:* 21 March 2016 19:36
> *To:* Emil Ivov <[email-masked]>
> *Cc:* Christer Holmberg <[email-masked]>; [email-masked]
> *Subject:* Re: [Ice] Some thoughts on trickling the ufrag
>
>     trickle ice is meant to be signalling agnostic. A headsup to
>     implementors may therefore be more appropriate.
>
>     Emil
>
>
>     On Sunday, 20 March 2016, Christer Holmberg
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         Hi,
>
>         *From:*Ice [mailto:[email-masked]] *On Behalf Of *Peter
>         Thatcher
>         *To:* [email-masked] <mailto:[email-masked]>
>         Earlier, we had some discussion around adding the ufrag to the
>         trickled candidate so that when one receives the a trickled
>         candidate after an ICE restart, it's clear if the candidate
>         applies to the ICE ufrag/pwd from before or after the ICE restart.
>
>         2.  We implemented the addition of the ufrag to candidates in
>         Chrome, and it fixed the issues observed.  Further, it was a
>         very easy fix.
>

-- 
https://jitsi.org

---

From: Peter Thatcher <[email-masked]>
Date: Wed, 30 Mar 2016 16:15:50 -0700

On Wed, Mar 30, 2016 at 3:20 PM, Emil Ivov <[email-masked]> wrote:

> addressing over the wire issues are supposed to be handled by other specs
> like Trickle ICE for SIP.
>
​I agree that generation doesn't need to be signalled, but the ufrag does,
as I'll explain further down.

> A WebRTC browser, when signalling candidates through the API does NOT need
> that at all because it can guarantee that candidates it trickles will be
> mappable to an SLD/SRD round.
>
>
​If there are multiple candidate gathering phases happening at the same
time right after an ICE restart, the WebRTC API does need to tell the
application ​which ufrag the candidate applies to so that the application
can signal that (via whatever signalling, not just SDP), so that the remote
side can know which pwd/ufrag to use when sending STUN messages.  Either
that or you say that after an ICE restart, you can't gather any more
candidates from the previous ufrag/pwd, which I don't think is reasonable.
  Assuming you do allow more candidates to be gathered after an ICE
restart, then you need to be able to tell if the candidate is for the
ufrag/pwd before or after the restart.

In other words, this isn't just a matter of message ordering or signalling
transport.

In a WebRTC 1.0 API, that means putting something like "ufrag foo" on the
a=candidate line.  In an ORTC-ish API, that means putting a .ufrag on the
IceCandidate object.

> sounds like the best path here. Normative language sounds like going out of
> scope for this draft.
>
​
​I think this doc should at least say "the ufrag of the candidate MUST be
signalled if the ufrag of the trickled candidate does match the ufrag since
the last ICE restart" or something along those lines.​

---

From: Emil Ivov <[email-masked]>
Date: Wed, 30 Mar 2016 21:04:45 -0500

On 30.03.16 г. 18:15, Peter Thatcher wrote:
>
> On Wed, Mar 30, 2016 at 3:20 PM, Emil Ivov <[email-masked]
> <mailto:[email-masked]>>wrote:
>
>     The whole part with the a= lines was only meant to be a convenience
>     but addressing over the wire issues are supposed to be handled by
>     other specs like Trickle ICE for SIP.
>
>     Whether or not the generation needs to be signalled depends entirely
>     on the transport.
>
>
> ​I agree that generation doesn't need to be signalled, but the ufrag
> does, as I'll explain further down.
>
>     SIP for example does allow for out of order messages so it
>     absolutely needs it and that's why that draft says:
>
>     A WebRTC browser, when signalling candidates through the API does
>     NOT need that at all because it can guarantee that candidates it
>     trickles will be mappable to an SLD/SRD round.
>
>
> time right after an ICE restart,

I am not sure I understand what this means -> "multiple candidate 
gathering phases happening at the same time"

Do you mean something like several PeerConnection-s restarting 
simultaneously? Or some ICE concurrent phases that have not been defined 
yet?

> the WebRTC API does need to tell the
> application ​which ufrag the candidate applies to so that the
> application can signal that (via whatever signalling, not just SDP), so
> that the remote side can know which pwd/ufrag to use when sending STUN
> messages.  Either that or you say that after an ICE restart, you can't
> gather any more candidates from the previous ufrag/pwd, which I don't
> think is reasonable.   Assuming you do allow more candidates to be
> gathered after an ICE restart, then you need to be able to tell if the
> candidate is for the ufrag/pwd before or after the restart.

ICE restarts can obviously yield new candidates and they all have a new 
ufrag/pwd that a WebRTC client will learn the same way it learned the 
first one: by getting the offer/answer from the browser.

In other words, during an ice restart, all checks have the same ufrag 
and password even if some or all the candidates are the same as before.

This is how 5245 works and there is no reason for trickle ICE to break 
that rule. In fact it strives to be backward compatible so ...

> In other words, this isn't just a matter of message ordering or
> signalling transport.
>
> In a WebRTC 1.0 API, that means putting something like "ufrag foo" on
> the a=candidate line.  In an ORTC-ish API, that means putting a .ufrag
> on the IceCandidate object.
>
>     sounds like the best path here. Normative language sounds like going
>     out of scope for this draft.
>
> ​
> ​I think this doc should at least say "the ufrag of the candidate MUST
> be signalled if the ufrag of the trickled candidate does match the ufrag
> since the last ICE restart" or something along those lines.​

The point is that it would never match the ufrag from before the 
restart, and yes it must be signalled exactly as the first one, but not 
on a per-candidate level.

Emil

>         *From:*Peter Thatcher [mailto:[email-masked]
>         <mailto:[email-masked]>]
>         *To:* Emil Ivov <[email-masked] <mailto:[email-masked]>>
>         *Cc:* Christer Holmberg <[email-masked]
>         <mailto:[email-masked]>>; [email-masked]
>         <mailto:[email-masked]>
>         On Sun, Mar 20, 2016 at 4:25 AM, Emil Ivov <[email-masked]
>         <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>              Well because it's a signaling issue. IIRC it is something
>         that we
>              agreed trickle ice for sip would
>              Include.
>
>              I guess it's more of a question if and how it should be in
>         trickle
>              ice for sip.
>
>         <mailto:[email-masked]>
>              <mailto:[email-masked]
>         <mailto:[email-masked]>>> wrote:
>
>                  Hi,
>
>                  *From:*Ice [mailto:[email-masked]
>         <mailto:[email-masked]>] *On Behalf Of *Peter
>                  Thatcher
>         <mailto:[email-masked] <mailto:[email-masked]>>
>                  3.  Do we have consensus in the group that we should
>         standardize
>                  this solution?
>
>                  4.  If so, should we simply add it to the trickle-ice
>         draft?  Or
>                  should it be a separate draft?
>
>                  Thanks,
>
>                  Peter
>
>              --
>              sent from my mobile
>
>
>     --
>     https://jitsi.org
>
>

-- 
https://jitsi.org

---

From: Peter Thatcher <[email-masked]>
Date: Wed, 30 Mar 2016 19:58:18 -0700

> gathering phases happening at the same time"
​A timeline like this:

1.  ufrag = X
2.  candidate 1 (tied to ufrag = X)
3.  restart to ufrag = Y
4.  candidate 2 (tied to ufrag = X)
5.  candidate 3 (tied to ufrag = Y)

When you receive candidate 2, how do you know which ufrag it's supposed to
have?​

This is the issue Lennox brought up in Yokohama.  And since then we have
observed it in production systems as well.  Either you disallow trickling
candidate 2 or you indicate somehow that its ufrag is X, not Y.  But you
can't trickle it without indicating that it has ufrag X.  Otherwise, you'd
think it was Y and be wrong.

> ufrag/pwd that a WebRTC client will learn the same way it learned the first
> one: by getting the offer/answer from the browser.

> In other words, during an ice restart, all checks have the same ufrag and
> password even if some or all the candidates are the same as before.
>

​You're assuming you can only send checks to one set of candidates at the
same time.  But if ICE wasn't complete when you restarted ICE, then you
have two sets of candidates you can send checks to: the ones from before
the restart, and the ones for after

> that rule. In fact it strives to be backward compatible so ...

​Except that if you are sending checks to two different sets of candidates
at the same time, you need to know which set a candidate belongs to.  So
you either say 5245 disallows sending checks to more than one set of
candidates at the same time (which I don't believe it does, and shouldn't),
or you disallow trickling candidates to the pre-restart set of candidates
(which would be suboptimal) or you indicate which set of candidates the
candidate applies to (its ufrag).

> The point is that it would never match the ufrag from before the restart,

First: why not match the ufrag from before?  Are you suggesting is
forbidden by the spec or allowed but not a good idea?

Secondly: production applications are already matching the ufrag from
before the restart.  That's why Lennox brought it up, and that's what
Chrome (and any mobile app using Chrome's ICE stack) does.  That's why
we're proposing adding ufrag to the candidate: it's a simple fix to a
production problem.

> and yes it must be signalled exactly as the first one, but not on a
> per-candidate level.

---

From: Emil Ivov <[email-masked]>
Date: Wed, 30 Mar 2016 22:35:26 -0500

On 30.03.16 г. 21:58, Peter Thatcher wrote:
>
>
> On Wed, Mar 30, 2016 at 7:04 PM, Emil Ivov <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>         <mailto:[email-masked] <mailto:[email-masked]>>>wrote:
>
> When you receive candidate 2, how do you know which ufrag it's supposed
> to have?​
>
> observed it in production systems as well.  Either you disallow
> trickling candidate 2 or you indicate somehow that its ufrag is X, not
> Y.  But you can't trickle it without indicating that it has ufrag X.
> Otherwise, you'd think it was Y and be wrong.

I think the confusion persists. I never said you shouldn't signal it. In 
fact in many cases, like SIP, you must or otherwise you get in ambiguous 
situations. That's why we added this to trickle ICE for SIP.

What I did say is that signalling is not always necessary, and I pointed 
out that the WebRTC API is one case where it is not.

>     simultaneously? Or some ICE concurrent phases that have not been
>     defined yet?
>
>     ICE restarts can obviously yield new candidates and they all have a
>     new ufrag/pwd that a WebRTC client will learn the same way it
>     learned the first one: by getting the offer/answer from the browser.
>
>
>     In other words, during an ice restart, all checks have the same
>     ufrag and password even if some or all the candidates are the same
>     as before.
>
>
> ​You're assuming you can only send checks to one set of candidates at
> the same time.

I am assuming no such thing. I think what might have led you to believe 
I did is my WebRTC example in which I said the browser didn't need to 
signal ufrag on a per-candidate level. And it doesn't. It should simply 
signal them in the offer or answer because they are the same for all 
candidates.

> But if ICE wasn't complete when you restarted ICE, then
> you have two sets of candidates you can send checks to: the ones from
> before the restart, and the ones for after

You absolutely do. There is no argument here.

>     This is how 5245 works and there is no reason for trickle ICE to
>     break that rule. In fact it strives to be backward compatible so ...
>
>
> ​Except that if you are sending checks to two different sets of
> candidates at the same time, you need to know which set a candidate
> belongs to.

Totally.

> So you either say 5245 disallows sending checks to more
> than one set of candidates at the same time (which I don't believe it
> does, and shouldn't), or you disallow trickling candidates to the
> pre-restart set of candidates (which would be suboptimal) or you
> indicate which set of candidates the candidate applies to (its ufrag).

I am saying neither of those two things. Could it be that you somehow 
assume that a candidate can only operate with one ufrag/password?

That is not the case.

After a restart, all of your candidates get a new ufrag. Including the 
ones that haven't changed at all. In WebRTC that ufrag and password get 
reported via the offer or answer and *all* candidates the browser 
reports beyond this point will implicitly have the new ufrag/password.

There won't be any need to indicate ufrags.

>     restart,
> First: why not match the ufrag from before?

Why not? Because it creates the very problem you are trying to solve here.

It also makes it impossible for the receiving agent to understand that a 
specific check belongs to a certain ICE session and that will break a 
lot of stuff.

> Are you suggesting is

Yes, as per 5245, ICE restarts mean all candidates get reported again 
and they *all* have the same/new ufrag and password.

> before the restart.

I have yet to see an application that does that. Even if we did find 
one, we simply can't write specs to match buggy stuff out 
there.Especially in disruptive cases like this one. If they are reusing 
ufrag-s they should fix it.

> That's why Lennox brought it up, and that's what

Wait ... what? I think I am losing you here. Are you implying that, 
after an ICE restart, Chrome somehow reports the old ufrag/pwd in the 
offer/answer but then uses a new one for newly discovered candidates?

I have never seen it do that but if it did ... how has that ever worked? 
How did the new ufrag get reported until now?

Emil

>         <mailto:[email-masked]>
>                  <mailto:[email-masked]
>         <mailto:[email-masked]>>]
>                  *To:* Emil Ivov <[email-masked]
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>>
>         <mailto:[email-masked]>>>; [email-masked]
>         <mailto:[email-masked]>
>                  Would it make sense to have a "SHOULD signal ufrag on a
>         trickled
>                  candidate"?
>
>                  On Sun, Mar 20, 2016 at 4:25 AM, Emil Ivov
>         <[email-masked] <mailto:[email-masked]>
>                  <mailto:[email-masked] <mailto:[email-masked]>>
>                  <mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>> wrote:
>
>                       The tricky part there is that this is a purely
>         signalling
>                  issue and
>         <mailto:[email-masked]>>
>         <mailto:[email-masked]>>>> wrote:
>
>                           Hi,
>
>                           What reason would there be for putting it in a
>         separate
>                  draft?
>
>                           Regards,
>
>                           Christer
>
>         <mailto:[email-masked]>
>                  <mailto:[email-masked]
>         <mailto:[email-masked]>>] *On Behalf Of *Peter
>                           Thatcher
>                  <mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>
>
>                           Earlier, we had some discussion around adding
>         the ufrag
>                  to the
>                           applies to the ICE ufrag/pwd from before or
>         after the
>                  ICE restart.
>
>                           Chrome, and it fixed the issues observed.
>         Further, it
>                  was a
>                           very easy fix.
>

-- 
https://jitsi.org

---

From: Emil Ivov <[email-masked]>
Date: Thu, 31 Mar 2016 11:44:32 -0500

More on Chrome supposedly doing ICE restart weirdness: I did play with 
it in our deployment and  here:

https://webrtc.github.io/samples/src/content/peerconnection/restart-ice/

And I saw no indication of the behaviour that you are describing: all 
candidates participate in the restart and they all have the new ufrag 
and pwd.

Am I missing something?

Emil

-- 
https://jitsi.org

---

From: Peter Thatcher <[email-masked]>
Date: Thu, 31 Mar 2016 10:33:06 -0700

> situations. That's why we added this to trickle ICE for SIP.

​Now I am confused.  ​
​
​ ​
You already adde
​d what to trickle ICE for SIP?  Trickling candidate 2 or including the
ufrag (I'm guessing the former)?

> I am assuming no such thing. I think what might have led you to believe I
> did is my WebRTC example in which I said the browser didn't need to signal
> ufrag on a per-candidate level. And it doesn't. It should simply signal
> them in the offer or answer because they are the same for all candidates.

> reported via the offer or answer and *all* candidates the browser reports
> beyond this point will implicitly have the new ufrag/password.
>

​So you're suggesting that (using my example), ​candidate 2 would accept
ICE checks from with either ufrag/pwd X or ufrag/pwd Y?  Or just ufrag/pwd
Y?

I had not considered that possibility.  It goes counter to what my
understanding of "make before break" ICE restart means.  My mental model of
a candidate is that it's tied to a ufrag/pwd, not that it can change during
an ICE restart.  Is there text in the RFCs/drafts that clarifies this, or
are we just reading our own different meanings into ambiguous text?

If this is true, what local ufrag would it use to send ICE checks on the
candidate pairs that existed before the ICE restart?  Would those suddenly
change from ufrag X to ufrag Y as well?  If so, when does that happen?
After sending the local offer to restart or receiving a remote answer
acknowledging the restart?

> specific check belongs to a certain ICE session and that will break a lot
> of stuff.
>
> Are you suggesting is
> Yes, as per 5245, ICE restarts mean all candidates get reported again and
> they *all* have the same/new ufrag and password.
>
> I have yet to see an application that does that. Even if we did find one,
> we simply can't write specs to match buggy stuff out there.Especially in
> disruptive cases like this one. If they are reusing ufrag-s they should fix
> it.
>
> Wait ... what? I think I am losing you here. Are you implying that, after
> an ICE restart, Chrome somehow reports the old ufrag/pwd in the

​The other way around.  It signals the new ufrag/pwd in offer/answer, and
then it signals the ufrag of the candidate, which may be the old ufrag or
the new, depending on if it's a candidate that applies to the set of
candidates before or after the ICE restart.