Subject: Re: [Ice] Some thoughts on trickling the ufrag

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 22 Jun 2016 21:04:12 -0600

On 3/31/16 11:33 AM, Peter Thatcher wrote:
>
>
> On Wed, Mar 30, 2016 at 8:35 PM, Emil Ivov <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     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]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>             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]>
>                 <mailto:[email-masked] <mailto:[email-masked]>>
>                 <mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>>wrote:
>
>                      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.
>
>
>                 ​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:
>
>                          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.
>
>
>                 ​If there are multiple candidate gathering phases
>         happening at
>                 the same
>                 time right after an ICE restart,
>
>
>             I am not sure I understand what this means -> "multiple
>         candidate
>             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.
>
>
>     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.
>
>
> ​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)?
>
>
>
>     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.
>
>
>
>             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.
>
>
>         ​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.
>
>
> ​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.

My mental model, too.

> Is there text in the RFCs/drafts that clarifies
> this, or are we just reading our own different meanings into ambiguous text?

IMHO restarts are underspecified (certainly with respect to trickling), 
which is why we're having this conversation.

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

I'd think it would be the latter.

>                 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.
>
>                      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.
>
>                 ​
>                 ​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,
>
>
>         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
>         forbidden by the spec or allowed but not a good idea?
>
>
>     Yes, as per 5245, ICE restarts mean all candidates get reported
>     again and they *all* have the same/new ufrag and password.
>
>         Secondly: production applications are already matching the ufrag
>         from
>         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
>         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.
>
>
>     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?
>
>
> ​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.

I think that makes sense.

How exactly does it signal the ufrag of the candidate? Let's say that 
before the restart it signalled 5 candidates. Does it resend all of 
those candidates after the restart and include the old ufrag?

Peter