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

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

Moving this from the MMUSIC list to the ICE list.

All of these seem like issues with aggressive nomination.  And 5245bis is
removing aggressive nomination.  So in a way, 5245bis solves these issues.
But it does have simplified rule for what to do when talking to a 5245
endpoint that does aggressive nomination, and we should probably make sure
that simple rule works well with what you are suggesting.  I agree that
receiving a nomination should not prevent triggered checks from occurring.

By the way, Chrome has the behavior you are describing where triggered
checks are not affected by aggressive nomination.

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

>     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
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>