Subject: Re: [Ice] Peter's review of ICEbis- Why do we nominate by putting the valid pair in the triggered check queue? (7.1.1)

From: Christer Holmberg <[email-masked]>
Date: Mon, 29 May 2017 06:38:29 +0000

Hi,

> - Why do we nominate by putting the valid pair in the triggered check queue?  Why not just say "send a binding request"?  In particular reason?
> Do we *want* it to be delayed if there are many things in the front of the queue?

I wonder whether the reason is to maintain the pacing among the CHECK LISTs, i.e., to make sure that the nomination request transaction for CHECK LIST X is not initiated at the same time as a connectivity check transaction for CHECK LIST Y?

But, even if we put the pair in the TRIGGERED CHECK LIST, we need to make sure it becomes the top-most pair in the list, because we don’t want to test other pairs that may still be i the list.

Regards,

Christer

---

From: Peter Thatcher <[email-masked]>
Date: Thu, 01 Jun 2017 01:15:40 +0000

The pacing rules are clear that they apply to all checks.  I don't think we
need to over-specify the algorithm for doing so.   And I don't think we
need to be over-specific about when the nominating check sent either.  Let
the agent/implementation decide.

On Sun, May 28, 2017 at 11:38 PM Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
> > - Why do we nominate by putting the valid pair in the triggered check
> queue?  Why not just say "send a binding request"?  In particular reason?
> I wonder whether the reason is to maintain the pacing among the CHECK
> LISTs, i.e., to make sure that the nomination request transaction for CHECK
> LIST X is not initiated at the same time as a connectivity check
> transaction for CHECK LIST Y?
>
> But, even if we put the pair in the TRIGGERED CHECK LIST, we need to make
> sure it becomes the top-most pair in the list, because we don’t want to
> test other pairs that may still be i the list.
>
> Regards,
>
> Christer
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 1 Jun 2017 06:27:44 +0000

Hi,

>The pacing rules are clear that they apply to all checks.

The question is whether we, for a given CHECK LIST, want to trigger a new connectivity check transaction (no matter whether it’s for nomination or not) only when Ta fires and that CHECK LIST is selected.

If we allow the implementation to send the nomination request “whenever it wants” there is always a chance that Ta fires for another CHECK LIST at the same time.

Having said that, if the connectivity check transaction already exists, and the only thing the agent does is setting the nomination flag, it’s not a new transaction, and it could be done at any time…

Regards,

Christer

  I don't think we need to over-specify the algorithm for doing so.   And I don't think we need to be over-specific about when the nominating check sent either.  Let the agent/implementation decide.

On Sun, May 28, 2017 at 11:38 PM Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer