Re: [rtcweb] FW: I-D Action: draft-muthu-behave-consent-freshness-03.txt

[Martin Thomson <[e-mail]>]

> In its current form, the draft uses the STUN transaction as defined in RFC5389, which implies the requests are retransmitted until a response is received, or until a total of 7 requests have been sent (assuming no hard ICMP error is received). So, reporting a consent freshness failure is sufficiently guarded against transitory network failures.

That's far too much.  And the backoff is designed for completely
different situations.

Imagine that you are running Tr at 1 second, with a complete
transaction required before you do anything.  Do you run 39 in
parallel with hundreds of checks, or do you not create a new
transaction when another is outstanding?  Keep in mind that the latter
choice means that you aren't really sending a check every second any
more, despite agreeing to do so.

> However, with the default 500 ms RTO recommended in RFC5389, it would take 39.5 sec for the transaction to timeout -- this was considered too long to declare a consent freshness failure.

We've discussed tightening the timers once the session is live.  We've
also discussed tightening timers when the session is starting.  Both
of which I would have expected to see in the document as proposed
solutions.

> One option could be to define a new STUN transaction that doesn't do the exponential backoff for retransmission, but instead retransmits at periodic intervals and declare failure if there is no response after sending a bunch of them, as you are suggesting. But, I am not sure at this point how that would be both superior compared to the transaction defined in RFC5389 and sufficiently guard against transitory network failures.

I think that the document only needs to talk in terms of "checks" or
Binding requests rather than transactions.