Subject: [MMUSIC] ICE triggered check behavior can backfire when using aggressive nomination

From: Byron Campen <[email-masked]>
Date: Fri, 6 May 2016 10:45:54 -0500

I've written out the details at 
https://bugzilla.mozilla.org/show_bug.cgi?id=1268961 , but the essence 
of the problem is that an incoming ICE check can cause a high priority 
in-progress pair to transition to waiting (due to the triggered check 
rules), which leaves it vulnerable to removal from the check list when 
nomination happens on a lower priority pair. Without the incoming ICE 
check, the high priority pair would have remained in-progress, and would 
eventually have reached nomination.

     It doesn't seem right to me that an incoming ICE check on a high 
priority pair could prevent that pair from reaching nomination when 
aggressive nomination is in use. It also doesn't seem right to me that 
receiving an incoming ICE check would cause a pair to transition from 
in-progress to waiting, given that the intent in the spec is to fast 
track that pair, and not put it on the back burner.

     It seems to me that prohibiting this in-progress -> waiting 
transition is the way to go, but it would also be reasonable to take 
priority into account when removing pairs from the triggered check queue 
(or maybe even never remove pairs from the triggered check queue).

Best regards,
Byron Campen

---

From: Peter Thatcher <[email-masked]>
Date: Fri, 6 May 2016 16:09:38 -0700

​Shouldn't this be posted to the ICE WG?​

On Fri, May 6, 2016 at 8:45 AM, Byron Campen <[email-masked]> wrote:

> https://bugzilla.mozilla.org/show_bug.cgi?id=1268961 , but the essence of
> the problem is that an incoming ICE check can cause a high priority
> in-progress to waiting, given that the intent in the spec is to fast track
> that pair, and not put it on the back burner.
>
>     It seems to me that prohibiting this in-progress -> waiting transition
> is the way to go, but it would also be reasonable to take priority into
> account when removing pairs from the triggered check queue (or maybe even
> never remove pairs from the triggered check queue).
>
> Best regards,
> Byron Campen
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>