Re: [rtcweb] Consent Freshness: Connection liveness/heartbeats

Here are my thoughts:
- Liveness was originally included in the document as a value added
feature; the same messages used for consent can be used to also determine
liveness and notify the application so that is can take some action before
consent expires. In a sense it is not liveness per se, rather an early
warning to the application before the doomsday.
- The application is free to choose its liveness interval (of course,
choosing an interval greater than the consent period isn't really useful).
If a valid STUN binding response corresponding to one of the STUN requests
sent in that interval has not been received, the browser notifies the
application. This doesn't require new STUN requests to be sent or a change
to how often they are sent for consent (and hence doesn't impact consent in
any way).

I see two options that wouldn't delay this work further:
1. Retain this simple functionality and fix the text, if we think this is
useful/sufficient for applications.
2. Remove liveness entirely from the document, if we need a full-fledged
liveness functionality. There are different ways of determining liveness
depending on the use case (RTCP, DTLS heartbeat, TCP keepalive etc), so we
could spin off a new doc and start with the problem/requirements.

Feedback from the WG would help (either way works for me, though).

Muthu

On Tue, Oct 14, 2014 at 12:09 PM, Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

>  Hi,
>
>
>
> I suggest that we REMOVE the liveness/heartbeats feature from the consent
> refresh draft. As I said earlier, I see no need for sending additional
> consent requests in addition to those already sent every 5th second.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> *From:* rtcweb [mailto:rtcweb-bounces@ietf.org] *On Behalf Of *Christer
> Holmberg
> *Sent:* 10 October 2014 15:23
> *To:* rtcweb@ietf.org
> *Subject:* [rtcweb] Consent Freshness: Connection liveness/heartbeats
>
>
>
> Hi,
>
>
>
> I have some questions on the connection liveness/heartbeat section of the
> draft.
>
>
>
>
>
> Q1:
>
> ===
>
>
>
> The text says:
>
>
>
>         “Similarly, if packets haven't been received within a certain
> period,
>
>         an application can request a consent check (heartbeat) be
> generated.”
>
>
>
> BUT, if an endpoint is anyway sending consent requests every 5th second,
> why aren’t the those enough as hearbeats? As long as the endpoint receives
> responses, it knows the remote endpoint is alive (the text even says that
> an endpoint is considered alive as long as some data is received from it).
>
>
>
> And, if the endpoint does NOT receive responses to the consent requests,
> consent will expire anyway.
>
>
>
> I DO understand that an ICE lite may want to send a heartbeat request if
> it does not receive any data, as it doesn’t send consent requests.
>
>
>
>
>
> Q2:
>
> ===
>
>
>
> The text says:
>
>
>
>         “Sending consent checks (heartbeats) at a high rate could allow a
>
>         malicious application to generate congestion, so applications MUST
>
>         NOT be able to send heartbeats at an average rate of more than 1 per
>
>         second.”
>
>
>
> I don’t think applications should be alowed to generate heartbeats this often, and I see no need for it.
>
>
>
>
>
> Q3:
>
> ===
>
>
>
> The spec is unclear on what happens is a response to a heartbeat request
> is not received. I guess that is an application decision, but I think the
> spec should be clear that it does NOT have any impact on consent – the
> “real” consent requests are used to determine.
>
>
>
>
>
> Regards,
>
>
>
> Christer
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>