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

[Christer Holmberg <[e-mail]>]

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 <[e-mail]<mailto:[e-mail]>>
Date: Thursday 1 March 2018 at 15:31
To: Ari Keränen <[e-mail]<mailto:[e-mail]>>
Cc: Christer Holmberg <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
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 <[e-mail]<mailto:[e-mail]>> wrote:
Hi Eric & Christer,

> On 19 Feb 2018, at 16.42, Eric Rescorla <[e-mail]<mailto:[e-mail]>> 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.

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

-Ekr



Cheers,
Ari (hat off)