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

From: Christer Holmberg <[email-masked]>
Date: Fri, 10 Oct 2014 12:22:43 +0000

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

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 14 Oct 2014 06:39:44 +0000

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:[email-masked]] On Behalf Of Christer Holmberg
Sent: 10 October 2014 15:23
To: [email-masked]
Subject: [rtcweb] Consent Freshness: Connection liveness/heartbeats

Hi,

Q1:
===

The text says:

Q2:
===

The text says:

        second."

Q3:
===

Regards,

Christer

---

From: Muthu Arul Mozhi Perumal <[email-masked]>
Date: Tue, 14 Oct 2014 14:02:34 +0530

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 <
[email-masked]> 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:[email-masked]] *On Behalf Of *Christer
> Holmberg
> *Sent:* 10 October 2014 15:23
> *To:* [email-masked]
> *Subject:* [rtcweb] Consent Freshness: Connection liveness/heartbeats
>
>
>
> Hi,
>
>
>
>         “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).
>
>
>
> 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
>
>         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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 14 Oct 2014 08:34:07 +0000

+1 for option 2 :)

Regards,

Christer

From: Muthu Arul Mozhi Perumal [mailto:[email-masked]]
Sent: 14. lokakuuta 2014 11:33
To: Christer Holmberg
Cc: [email-masked]
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.

Muthu

On Tue, Oct 14, 2014 at 12:09 PM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer

From: rtcweb [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Christer Holmberg
Sent: 10 October 2014 15:23
To: [email-masked]<mailto:[email-masked]>
Subject: [rtcweb] Consent Freshness: Connection liveness/heartbeats

Hi,

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).

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:

        second.”

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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Tue, 14 Oct 2014 10:28:59 +0000

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.
<Raju>
Liveliness can and has to be detected at each level. For e.g. lack of RTCP could be caused of lack of STUN liveliness or crash of RTP/RTCP endpoint; it is crucial to know the exact cause for debugging purpose.
I am ok with either option, with a slight lean towards a separate draft, as long as liveliness at all levels are captured; either in one single combined draft or in respective drafts.
</Raju>