Re: [MMUSIC] Trickle ICE

[Emil Ivov <[e-mail]>]

Hey Martin,

On 12.10.12, 18:55, Martin Thomson wrote:
> Emil,
> 
> On 11 October 2012 14:34, Emil Ivov <[e-mail]> wrote:
>>> Actually, this part in Section 9 wasn't very clear.
>>
>> Sorry about that. We'll try to add clarifications before the 01 deadline.
> 
> Actually, I think that we've just uncovered a case of talking past
> each other.  I was talking about the inter-component interactions and
> you were talking about the interactions intra-component.

Do you mean inter/intra-checklist?

> It's seems obvious to me now that there needs to be more certainty
> about the interactions on both axes.

I do believe we mention both of those but there are probably a number of
things still missing. We'll be reviewing the text in the following days
but if you can describe specific scenarios that you believe are not
currently covered, this would be very helpful.

> There are clearly interactions on the one component, but I'm not sure
> that the conclusions that you have drawn are necessarily optimal.

Completely possible.

> When you make the choice to cancel an outstanding transaction, you
> don't do anything other than increase the probability of success.  The
> Binding requests from the lower priority pair have gone out and may
> still succeed, assuming of course that both peers are opening
> pinholes.

Well, the reason we cancel and then restart transactions is exactly
because both peers have most probably not opened pinholes.

I do however agree that in certain situations transactions may be
cancelled when they were just about to succeed, but I also think this
would be fairly easy to cover: as you suggested yourself - we just need
to declare the check successful.

> Cancelling the transaction at this point seems counterproductive.
> Instead, adding the new pair to the check list such that a transaction
> is created in response to the next ordinary check timer pop ensures
> that checks proceed on the new pair as soon as is reasonable

I agree and I also believe that this is exactly what the text says right
now.

>, while
> allowing the lower priority pair to move to the Failed or Succeeded
> state normally.
> 
> This may result in a lower priority pair reaching Succeeded before the
> higher priority one, but that was an inevitable consequence of the
> sequencing anyhow.

I agree and I think that if a check succeeds while it is being
cancelled, we don't necessarily need to insist on the higher priority,
redundant pair succeeding. I suppose in we can maybe keep them this way
(that is, the lower prio as successful and the higher prio as failed).

However if it doesn't and the transaction is properly cancelled then we
may just as well reschedule it for the higher prio pair.
> 
>>> 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.
> 
> That's an interesting choice.  I tend to prefer don't-even-try
> solutions to try-fail-and-fallback ones if at all possible.  They tend
> to be more robust because your legacy peer doesn't get in a messed up
> state due to the failure.

It's funny how I find my self on exactly the opposite sides of the same
argument in two concurrent threads :).

Yes, check-before-trying is definitely better, which is why we currently
have it as a SHOULD in the draft. The sentence that you are commenting
on was just an example of an alternative way of doing the same thing for
protocols that don't have decent Caps negotiation, like SIP.

My conversation with Christer was about me desperately insisting that
there might be a way to do this with SIP, and him persuading me that
there isn't and that we should keep this in mind when designing base
trickle.

I still think that using things like XMPP disco info and entity
capabilities is best when available.

>>> 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?
> 
> 5245 doesn't really have the concept of re-freezing a pair, does it?

No, and neither do we. 5245 defines the concept of cancelling a
transaction however and it doesn't cover the case where it succeeds
while being cancelled. It might be worth doing it.

Cheers,
Emil





-- 
https://jitsi.org