Re: [MMUSIC] Trickle ICE

[Emil Ivov <[e-mail]>]

Hey Martin,

On 11.10.12, 19:13, Martin Thomson wrote:
> On 10 October 2012 15:46, Emil Ivov <[e-mail]> wrote:
>> Yes, the above sentence may indeed be misleadingly read as "respecting
>> the order of the streams is all there is to it". What was really meant
>> was something along the lines of: "respecting the order of streams
>> improves the chances of the connectivity checks being run simultaneously
>> for a particular stream/component"
>>
>>> A naive implementation would use the set of known candidates on each
>>> component to make this determination.  However, that set is
>>> potentially different to the set of candidates known to their peer.
>>> That could cause a mismatch if both peers "unfreeze the first
>>> non-empty checklist."
>>
>> Correct, but this is not going to be a problem. When the corresponding
>> candidates eventually find their way to the agent, it would unfreeze
>> their local counter-parts and, if necessary, rerun any in-progress or
>> failed checks. This is explained in Section 9:
>>
>>    [snip] the agent examines the check
>>    list looking for another pair that would be redundant with the new
>>    one.  If such a pair exists and its state is:
>>
>>    Failed:   the agent chooses the pair with the higher priority local
>>       candidate, places it in the Waiting state and removes the other
>>       one as redundant.
>>    In-Progress:   The agent cancels the in-progress transaction (where
>>       cancellation happens as explained in Section 7.2.1.4 of
>>       [RFC5245]), then it chooses the pair with the higher priority
>>       local candidate, places it in the Waiting state and removes the
>>       other one as redundant.
>>
>> Does this sound reasonable or were you referring to something else?
> 
> Actually, this part in Section 9 wasn't very clear. 

Sorry about that. We'll try to add clarifications before the 01 deadline.

> I think that the
> terms aren't quite right.  "Redundant" and "priority" have specific
> meanings in ICE that I think aren't quite right for using here.

Yes they do, and those same meanings apply here.

> This wasn't immediately clear, though I get where you are going with
> this.  Though I do think that you need to ensure that this
> cancellation doesn't occur to the highest priority"

Why not?

> You aren't talking about priority or redundancy, I think. 

I believe we are.

> You want to
> ensure that you are making checks on the first component (of the first
> media stream). 

No, not really. What we want to ensure is that if a number of checks
fail because pairs are in an asymmetric state, those checks will be
retried later.

Imagine the following case (described by Eric in his original mail to
RTCWEB):

* Alice calls Bob with a list containing server reflexive candidates.
* Bob responds with host candidates only.
* Bob then starts checks but the pairs containing Alice's server
reflexive address won't be succeeding because Alice is not doing checks
to open up the filtering on the NAT.
* Bob then gets SR addresses and sends them to Alice so she also starts
conn checks.
* With the rules in Secion 9, Bob also places the pairs that failed just
above into the Waiting state, so this time checks are simultaneous and
they succeed.

> What you want is probably more like:
> 
> The agent examines the check list 

When is this happening? When learning new local candidates? Remote? In
the beginning of ICE processing? At some other point?

> and looks for a pair with the same
> foundation.  Where multiple such pairs exist, the one from the
> component that is first in order is selected.  If an existing pair is
> selected, based on its state, the following actions are taken:
> 
>  Failed:  The agent marks the new pair as Failed.  [[?: not sure that
> this is entirely safe, might need to re-open this one to prevent a
> race condition...]]
>  In-Progress: If the new pair is for a component [[i.e. media stream +
> component]] after the existing pair, the new pair is Frozen.  If the
> new pair is for a component that comes before the existing pair's
> component the existing pair becomes Frozen, the outstanding
> transaction on the existing pair is cancelled, and the new pair is
> placed in the Waiting state.
>   Waiting: If the new pair is for a component [[i.e. media stream +
> component]] after the existing pair, the new pair is Frozen.  If the
> new pair is for a component that comes before the existing pair's
> component the existing pair becomes Frozen and the new pair is placed
> in the Waiting state.
>  etc...
> 
> Does *that* make sense?

Not entirely ;)

Could you please describe a scenario that you think would file with the
text currently in the draft, and that would succeed with the above?

>> Mmm ... it might be my lack of IETF experience, but aren't references
>> supposed to happen the other way around? That is, if RTCWEB decides to
>> use Trickle ICE, then shouldn't RTCWEB documents be referring to this
>> spec and making whatever normative declarations they find appropriate?
> 
> Yes, but the draft makes the claim about a WebRTC app that is
> contacting peers in the same domain.  This makes a big assumption:
> namely, that ALL the other entities in that domain implement trickle
> ICE.  I infer from this that you are assuming that rtcweb is going to
> make this MUST implement, so that you can at least expect all browsers
> to implement trickle ICE.  That is if you are assuming that the same
> domain is only using browsers.

Oh right. We'll make sure the assumption is stated.

>> Besides, trickle ICE is already in use by XMPP apps and SIP will
>> probably follow. Why would the RTCWEB usage be referred to and not the
>> others?
> 
> SIP may well follow, but that doesn't mean that you can make any
> assumptions about support.
> 
>>> In particular, this relates to the decision to require
>>> signaling of support for trickle ICE outside of SDP (a decision that I
>>> need to think about a little more).
>>
>> Well the idea is that it doesn't really need to be signalling. The
>> example that we give is about a WebRTC app with no cross domain support.
>> In this case the WebRTC app can just enable trickle ICE without checking
>> anything since the remote agent is bound to have it too. Again, it's
>> just an example. We are not saying this is how it's going to be done for
>> RTCWEB.
> 
> You can't send an offer sans candidates and expect it to work. 

Indeed not. I would expect it to fail for non-trickle agents (without
alerting the remote user) which would then be my cue to fallback to
vanilla ICE.

> Note: we probably also need to note that a transaction can succeed for
> a Frozen candidate pair (due to the fact that you can't take a STUN
> packet back, so "cancelling" a transaction might still result in a
> successful Binding response.  I don't know what you would do with
> this, but I'd just move the pair to Succeeded.

The case where a cancelled transaction ends up succeeding is indeed
worth covering, but given how the concept is defined in 5245 then maybe
at least part of the coverage should go in 5245bis?


Cheers,
Emil

> That's
> part of the reason you are writing this draft, as I understand.
> Unless you know for certain that the other side implements it.  I
> don't think that this is realistic.  Therefore, signaling.
> 
>> Does this make sense?
> 
> Not entirely ;)
>