Subject: [Ice] 5245bis: To cancel or not to cancel an In-Progress transaction

From: Christer Holmberg <[email-masked]>
Date: Wed, 18 Oct 2017 09:49:32 +0000

Hi,

Section 6.3.1.4. (Triggered Checks) of 5245bis says:

       "If the state of that pair is In-Progress, the agent cancels the
        in-progress transaction. <snap> In addition, the agent
        MUST create a new connectivity check for that pair"

Section 6.3.1.5. (Updating the Nominated Flag) says:

      "If the state of this pair is In-Progress, and if its check
      produces a successful result, the resulting valid pair has its
      nominated flag set when the response arrives."

First, I think the text is conflicting, because section 6.3.1.5 doesn’t say anything about cancelling in ongoing (In-Progress) transaction.

Second, Regarding 6.3.1.4, why does one have to cancel the transaction and create a new one?

Regards,

Christer

---

From: Taylor Brandstetter <[email-masked]>
Date: Wed, 18 Oct 2017 09:35:12 -0700

I don't see how these are at odds. 6.3.1.5 doesn't have to say anything
about canceling transactions because 6.3.1.4 already does. And you left out
an important part of 6.3.1.4:

         Cancellation means that the agent
>          will not retransmit the request, will not treat the lack of
>          response to be a failure, but will wait the duration of the
>          transaction timeout for a response.

The point of canceling the request and generating a new one is (I'm
assuming) to refresh the exponentially increasing retransmission timeout.
If the peer just punched a hole in its NAT, you want to send another
connectivity check as soon as possible to take advantage of this. But it's
still possible to receive a response for the connectivity check that was
canceled, and this is treated as success.

It would be nice if this were explained a bit more. The explanation in the
spec is not very helpful:

   These steps are done to facilitate rapid completion of ICE when both
>    agents are behind NAT.

On Wed, Oct 18, 2017 at 2:49 AM, Christer Holmberg <
[email-masked]> wrote:

> First, I think the text is conflicting, because section 6.3.1.5 doesn’t
> say anything about cancelling in ongoing (In-Progress) transaction.
>
> _______________________________________________
> Ice mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ice
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 18 Oct 2017 20:48:01 +0000

Hi,

>I don't see how these are at odds. 6.3.1.5 doesn't have to say anything about canceling transactions because 6.3.1.4 already does. And you left out an 
>important part of 6.3.1.4:
>
>The point of canceling the request and generating a new one is (I'm assuming) to refresh the exponentially increasing retransmission 
>timeout. If the peer just punched a hole in its NAT, you want to send another connectivity check as soon as possible to take advantage 
>of this. But it's still possible to receive a response for the connectivity check that was canceled, and this is treated as success.

Let's assume I have a pair in In-Progress state (ongoing check A).

I receive a connectivity check with USE-CANDIDATE.

I trigger a new check (check B), according to the text in 6.1.3.4.

Now, the text in 6.1.3.5 says "and if its check produces a successful result,".

Which check is the text talking about? A or B? As one may fail (at least in theory), I need to know which one has to succeed.

Perhaps the text should say "and if its MOST RECENT check produces a successful result,".

Regards.

Christer

It would be nice if this were explained a bit more. The explanation in the spec is not very helpful:

On Wed, Oct 18, 2017 at 2:49 AM, Christer Holmberg <[email-masked]> wrote:
Hi,

Regards,

Christer

---

From: Taylor Brandstetter <[email-masked]>
Date: Wed, 18 Oct 2017 14:13:57 -0700

>
> Which check is the text talking about? A or B?

Either one. Would this be clear enough if "its check" was changed to "one
of its checks"? Or the whole sentence could be reworded to something like:

"If the state of this pair is not yet Succeeded, then the nominated flag
will be set on the valid pair generated if and when it does become
Succeeded."

On Wed, Oct 18, 2017 at 1:48 PM, Christer Holmberg <
[email-masked]> wrote:

> assuming) to refresh the exponentially increasing retransmission
> >timeout. If the peer just punched a hole in its NAT, you want to send
> another connectivity check as soon as possible to take advantage
> >of this. But it's still possible to receive a response for the
> connectivity check that was canceled, and this is treated as success.
>
> Which check is the text talking about? A or B? As one may fail (at least
> in theory), I need to know which one has to succeed.
>