Subject: Re: [Ice] Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security Considerations)

From: Ari Keränen <[email-masked]>
Date: Thu, 1 Mar 2018 08:58:58 +0000

Hi Eric & Christer,

> On 19 Feb 2018, at 16.42, Eric Rescorla <[email-masked]> wrote:
> 
>  
> 
> >         in-progress transaction.  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
> >
> > Why are you cancelling In-Progress checks when you receive a peer-reflective check?
> > If you receive two in a row, then it seems like this delays a successful check.
> 
> True.
> 
> So, I will remove the cancel part.
> 
> Do you still think it should create a new binding request, or is the ongoing In-Progress check enough to check the pair?
> 
> My initial reaction is you don't need to do anything extra, but I could easily be wrong here.

I'm afraid this is one of the parts of the spec that solves a corner case in an interesting but non-obvious way. For context, here's the original text:
https://tools.ietf.org/html/rfc5245#section-7.2.1.4

IIRC, one of the reasons for this is that an agent might have started the transaction a while ago, perhaps even sent a few re-transmissions. Now, if you don't cancel that transaction, but just keep that going and send the remaining re-transmission(s) and those are lost due to bad network connectivity, you end up marking that pair as failed. However, if you cancel and start a new transaction, you have full amount of fast retransmissions to go. And if you receive a reply to a cancelled check, it is still a success. I remember this was unintuitive but eventually made sense when I implemented it.

So, I'd recommend we keep this text as such.

Cheers,
Ari (hat off)

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 1 Mar 2018 05:31:37 -0800

On Thu, Mar 1, 2018 at 12:58 AM, Ari Keränen <[email-masked]>
wrote:

> > Do you still think it should create a new binding request, or is the
> ongoing In-Progress check enough to check the pair?
> >
> I'm afraid this is one of the parts of the spec that solves a corner case
> in an interesting but non-obvious way. For context, here's the original
> text:
> IIRC, one of the reasons for this is that an agent might have started the
> transaction a while ago, perhaps even sent a few re-transmissions. Now, if
> you don't cancel that transaction, but just keep that going and send the
> remaining re-transmission(s) and those are lost due to bad network
> connectivity, you end up marking that pair as failed. However, if you
> cancel and start a new transaction, you have full amount of fast
> retransmissions to go. And if you receive a reply to a cancelled check, it
> is still a success. I remember this was unintuitive but eventually made
> sense when I implemented it.
>

Why is this different from any other case of transient failure?

-Ekr

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 1 Mar 2018 14:09:43 +0000

Hi,

I guess Ari will reply, but my understanding is that, since triggered checks have high priority, we want the triggered binding requests to be sent asap. But, if the ongoing transaction (In-Progress) has already been going on for a while, and all transmitted/re-transmitted binding requests so far for whatever reason have got dropped in the network, due to the current re-transmission timer (which grows after each re-transmission) it may take a while before binding check is re-transmitted again.

(Of course, even if we create a new transaction, there may be other checks waiting in the triggered check queue, so it may still take a while before the new binding check is sent.)

Regards,

Christer

From: Eric Rescorla <[email-masked]<mailto:[email-masked]>>
Date: Thursday 1 March 2018 at 15:31
To: Ari Keränen <[email-masked]<mailto:[email-masked]>>
Cc: Christer Holmberg <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security Considerations)

On Thu, Mar 1, 2018 at 12:58 AM, Ari Keränen <[email-masked]<mailto:[email-masked]>> wrote:
Hi Eric & Christer,

> On 19 Feb 2018, at 16.42, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:
>
>
>

-Ekr

Cheers,
Ari (hat off)

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 2 Mar 2018 13:17:49 +0000

So, what to do?

From: Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Date: Thursday 1 March 2018 at 16:09
To: Eric Rescorla <[email-masked]<mailto:[email-masked]>>, Ari Keränen <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security Considerations)
Resent-From: <[email-masked]<mailto:[email-masked]>>
Resent-To: Ari Keränen <[email-masked]<mailto:[email-masked]>>, Christer Holmberg <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Resent-Date: Thursday 1 March 2018 at 16:09

Hi,

Regards,

Christer

-Ekr

Cheers,
Ari (hat off)

---

From: Ari Keränen <[email-masked]>
Date: Fri, 2 Mar 2018 14:24:13 +0000

I agree with what you wrote below. I think the best way forward is to keep the text as it was in -17. Anyway it was part of the original RFC5245 text and as discussed earlier, when in doubt, it's better we don't change the text and accidentally change the behavior for the worse.

Cheers,
Ari

> On 2 Mar 2018, at 15.17, Christer Holmberg <[email-masked]> wrote:
> 
> So, what to do?
> 
> From: Christer Holmberg <[email-masked]>
> To: Eric Rescorla <[email-masked]>, Ari Keränen <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
> Resent-From: <[email-masked]>
> Resent-To: Ari Keränen <[email-masked]>, Christer Holmberg <[email-masked]>, "[email-masked]" <[email-masked]>
> From: Eric Rescorla <[email-masked]>
> To: Ari Keränen <[email-masked]>
> Cc: Christer Holmberg <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
> On Thu, Mar 1, 2018 at 12:58 AM, Ari Keränen <[email-masked]> wrote:
>> Hi Eric & Christer,
>>

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 2 Mar 2018 06:47:31 -0800

Ari

Well, this is a nonblocking comment, so fo as you please, but I think that
at minimum this is a confusing behavior and it's the job of the document to
explain it.

On Fri, Mar 2, 2018 at 6:24 AM, Ari Keränen <[email-masked]>
wrote:

> I agree with what you wrote below. I think the best way forward is to keep
> the text as it was in -17. Anyway it was part of the original RFC5245 text
> and as discussed earlier, when in doubt, it's better we don't change the
> text and accidentally change the behavior for the worse.
>
>
> Cheers,
> Ari
>
> > Cc: "[email-masked]" <[email-masked]>, "[email-masked]"
> <[email-masked]>, "[email-masked]" <
> [email-masked]>, "[email-masked]" <[email-masked]>, "
> [email-masked]" <[email-masked]>
> > Subject: Re: Eric Rescorla's No Objection on
> draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security
> Considerations)
> > Resent-To: Ari Keränen <[email-masked]>, Christer Holmberg <
> [email-masked]>, "[email-masked]" <
> [email-masked]>
> > I guess Ari will reply, but my understanding is that, since triggered
> checks have high priority, we want the triggered binding requests to be
> sent asap. But, if the ongoing transaction (In-Progress) has already been
> going on for a while, and all transmitted/re-transmitted binding requests
> so far for whatever reason have got dropped in the network, due to the
> current re-transmission timer (which grows after each re-transmission) it
> may take a while before binding check is re-transmitted again.
> >
> > (Of course, even if we create a new transaction, there may be other
> checks waiting in the triggered check queue, so it may still take a while
> before the new binding check is sent.)
> >
> > Regards,
> >
> > Christer
> >
> > Cc: Christer Holmberg <[email-masked]>, "[email-masked]"
> <[email-masked]>, "[email-masked]" <
> [email-masked]>, "[email-masked]" <
> [email-masked]>, "[email-masked]" <[email-masked]>, "
> [email-masked]" <[email-masked]>
> > Subject: Re: Eric Rescorla's No Objection on
> draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security
> Considerations)
> >
> >
> >
> >> I'm afraid this is one of the parts of the spec that solves a corner
> case in an interesting but non-obvious way. For context, here's the
> original text:
> >> IIRC, one of the reasons for this is that an agent might have started
> the transaction a while ago, perhaps even sent a few re-transmissions. Now,
> if you don't cancel that transaction, but just keep that going and send the

---

From: Ari Keränen <[email-masked]>
Date: Fri, 2 Mar 2018 15:40:17 +0000

Hi Eric,

Maybe the specific bullet could also be augmented with something like: "This enables validating In-Progress pairs as soon as possible, without having to wait for re-transmissions of the original transaction."

Would that clarify this sufficiently?

Note that a response to a cancelled check also still qualifies as a successful check. Only the retransmissions and "fail this candidate if no answer" behavior is cancelled, so there is no extra delay because of this behavior even if the original check would eventually succeed. The text says about cancel case: "[...] but will wait the duration of transaction timeout for a response".

Cheers,
Ari

> On 2 Mar 2018, at 16.47, Eric Rescorla <[email-masked]> wrote:
> 
> Ari
> 
> Well, this is a nonblocking comment, so fo as you please, but I think that at minimum this is a confusing behavior and it's the job of the document to explain it.
> 
> On Fri, Mar 2, 2018 at 6:24 AM, Ari Keränen <[email-masked]> wrote:

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 2 Mar 2018 07:51:40 -0800

On Fri, Mar 2, 2018 at 7:40 AM, Ari Keränen <[email-masked]>
wrote:

> Hi Eric,
>
> Maybe the specific bullet could also be augmented with something like:
> "This enables validating In-Progress pairs as soon as possible, without
> having to wait for re-transmissions of the original transaction."
>

Yes, that would be fine

-Ekr

> Note that a response to a cancelled check also still qualifies as a
> successful check. Only the retransmissions and "fail this candidate if no
> answer" behavior is cancelled, so there is no extra delay because of this
> behavior even if the original check would eventually succeed. The text says
> about cancel case: "[...] but will wait the duration of transaction timeout
> for a response".
>
>
> Cheers,
> Ari
>
> > Well, this is a nonblocking comment, so fo as you please, but I think
> that at minimum this is a confusing behavior and it's the job of the
> document to explain it.
> >
> > I agree with what you wrote below. I think the best way forward is to
> keep the text as it was in -17. Anyway it was part of the original RFC5245
> text and as discussed earlier, when in doubt, it's better we don't change
> the text and accidentally change the behavior for the worse.
> >
> >
> > Cheers,
> > Ari
> >
> > > Cc: "[email-masked]" <[email-masked]>, "draft-ietf-ice-rfc5245bis@
> ietf.org" <[email-masked]>, "[email-masked]" <
> > >> > Do you still think it should create a new binding request, or is
> the ongoing In-Progress check enough to check the pair?
> > >> >

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 2 Mar 2018 21:02:54 +0000

Hi,

I’ve updated the security considerations pull request:

https://github.com/ice-wg/rfc5245bis/pull/61/commits/a14001cafd622235c7bc22443db4aa0d8269fef2

I did some editorial clean-ups and terminology alignments in the text of the bullets, but technically it is now as in version -17.

Regards,

Christer

From: Eric Rescorla [mailto:[email-masked]]
Sent: 02 March 2018 17:52
To: Ari Keränen <[email-masked]>
Cc: Christer Holmberg <[email-masked]>; The IESG <[email-masked]>; [email-masked]; [email-masked]; Peter Thatcher <[email-masked]>; [email-masked]
Subject: Re: Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security Considerations)

On Fri, Mar 2, 2018 at 7:40 AM, Ari Keränen <[email-masked]<mailto:[email-masked]>> wrote:
Hi Eric,

Yes, that would be fine

-Ekr

Cheers,
Ari

> On 2 Mar 2018, at 16.47, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:
>
> Ari
>
> On Fri, Mar 2, 2018 at 6:24 AM, Ari Keränen <[email-masked]<mailto:[email-masked]>> wrote:
> > On 2 Mar 2018, at 15.17, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
> >
> > So, what to do?
> >