Re: [rtcweb] Review of draft-ietf-rtcweb-stun-consent-freshness

[Martin Thomson <[e-mail]>]

On 1 June 2015 at 15:06, Bernard Aboba <[e-mail]> wrote:
> Comments on the PR:
>
> +pair when the pair enters Succeeded ICE state.  consent; this document
> +establishes a 30 second expiry time on consent.
>
> [BA] Is the text starting from "consent;" intended to be there? Looks like a
> cut/paste error.

The latter statement was intended to be there.

> [BA] If a response still has not been received, but the RTO timer has not
> expired, why should consent be revoked just because the 30 second timer
> elapsed? As an example, if a request is sent at 29.9 seconds, and the RTO
> timer is 2 seconds, why should consent be revoked only 100 ms after sending
> the request?? Also, this text does not appear consistent with the text
> below:

If you sent something 100ms ago, then it might be useful in the
future, but for now, your consent has expired.  Extending the window
to max(30, Tlast-request + RTO) is extending the window.  It's also
more complicated to implement.

I'm not sure how that would be inconsistent; the text below says that
consent expiry is independent of check interval.

If I were to implement this (as I once did), I would initiate a check
every 5s, awaiting a response for each separately.  If one of those
succeeded, I would update a "lastSuccessfulCheck" variable to the
current time.

Then when sending, I would check that "lastSuccessfulCheck" is more
recent than (now - 30s).  If so, explode.

Or you can run a 30s timer that you reset each time a check succeeds.
Explode if it ever actually runs to completion without being reset.

Neither of those needs to care about RTO.  The implementation of the
checking might (in practice, you can just wait.

> +An endpoint SHOULD await a binding response for each request it sends for a
> time
> +based on the estimated round-trip time (RTT) (see Section 7.2.1 of <xref
> +target="RFC5389"/>) with an allowance for variation in network delay.  The
> RTT
> +value can be updated as described in <xref target="RFC5389"/>.  After this
> time
> +elapses, an endpoint can discard associated state and ignore any late
> responses.
>
> [BA] I do not understand why responses arriving after the RTO timer expires
> are completely ignored.  Post-RTO responses not only indicate that consent
> has been maintained, but also that the RTO needs to be revised upwards.  So
> I would consider deleting the last sentence.

OK.  Done.

>
> +All outstanding STUN consent transactions for a candidate pair MUST be
> discarded
> +when consent expires.
>
> [BA] This part does make sense.  But overall, the paragraph seems to
> indicate that consent expires at max(30, Tlast-request + RTO), not 30
> seconds.

I don't know how you get that.  It's certainly isn't the intent.