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

+1 for option 2 :)

Regards,

Christer

From: Muthu Arul Mozhi Perumal [mailto:muthu.arul@gmail.com]
Sent: 14. lokakuuta 2014 11:33
To: Christer Holmberg
Cc: rtcweb@ietf.org
Subject: 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<mailto: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<mailto:rtcweb-bounces@ietf.org>] On Behalf Of Christer Holmberg
Sent: 10 October 2014 15:23
To: rtcweb@ietf.org<mailto: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<mailto:rtcweb@ietf.org>
https://www.ietf.org/mailman/listinfo/rtcweb