[PATCH 3/3] sctp: add heartbeat expired counter to /proc/net/sctp/snmp

[PATCH 3/3] sctp: add heartbeat expired counter to /proc/net/sctp/snmp

[Shan Wei]

Just like T4-RTO, T3-RXT timeout events, add HEARTBEAT timeout
counter for debug. It is useful because all these timeout events
cause association error counter to increase.


Signed-off-by: Shan Wei <shanwei@cn.fujitsu.com>
---
 include/net/sctp/sctp.h |    1 +
 net/sctp/proc.c         |    1 +
 net/sctp/sm_statefuns.c |    2 ++
 3 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h
index 65946bc..f7fb5de 100644
--- a/include/net/sctp/sctp.h
+++ b/include/net/sctp/sctp.h
@@ -263,6 +263,7 @@ enum {
 	SCTP_MIB_IN_PKT_BACKLOG,
 	SCTP_MIB_IN_PKT_DISCARDS,
 	SCTP_MIB_IN_DATA_CHUNK_DISCARDS,
+	SCTP_MIB_HEARTBEAT_EXPIREDS,
 	__SCTP_MIB_MAX
 };
 
diff --git a/net/sctp/proc.c b/net/sctp/proc.c
index 5584d1a..53263ca 100644
--- a/net/sctp/proc.c
+++ b/net/sctp/proc.c
@@ -74,6 +74,7 @@ static const struct snmp_mib sctp_snmp_list[] = {
 	SNMP_MIB_ITEM("SctpInPktDiscards", SCTP_MIB_IN_PKT_DISCARDS),
 	SNMP_MIB_ITEM("SctpInDataChunkDiscards", SCTP_MIB_IN_DATA_CHUNK_DISCARDS),
 	SNMP_MIB_ITEM("SctpT1Retransmits", SCTP_MIB_T1_RETRANSMITS),
+	SNMP_MIB_ITEM("SctpHeartbeatExpireds", SCTP_MIB_HEARTBEAT_EXPIREDS),
 	SNMP_MIB_SENTINEL
 };
 
diff --git a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c
index 24b2cd5..8d3e223 100644
--- a/net/sctp/sm_statefuns.c
+++ b/net/sctp/sm_statefuns.c
@@ -974,6 +974,8 @@ sctp_disposition_t sctp_sf_sendbeat_8_3(const struct sctp_endpoint *ep,
 {
 	struct sctp_transport *transport = (struct sctp_transport *) arg;
 
+	SCTP_INC_STATS(SCTP_MIB_HEARTBEAT_EXPIREDS);
+
 	if (asoc->overall_error_count >= asoc->max_retrans) {
 		sctp_add_cmd_sf(commands, SCTP_CMD_SET_SK_ERR,
 				SCTP_ERROR(ETIMEDOUT));
-- 
1.7.0

Re: [PATCH 3/3] sctp: add heartbeat expired counter to /proc/net/sctp/snmp

[Vlad Yasevich]

Shan Wei wrote:
> Just like T4-RTO, T3-RXT timeout events, add HEARTBEAT timeout
> counter for debug. It is useful because all these timeout events
> cause association error counter to increase.
> 

Unlinke T4-RTO and T3-RTO, heartbeat timeouts happen all the time
and do not necessarily mean that a something is wrong.

This mib item is not going to provide any useful information since it's
going to wrap around way too fast, especially since use has the control
to set the HB interval extremely low, thus generating a ton of timeouts.

It may be worth tracking the number of non-responded heartbeats, since those
will actually cause association destruction.

-vlad

> 
> Signed-off-by: Shan Wei <shanwei@cn.fujitsu.com>
> ---
>  include/net/sctp/sctp.h |    1 +
>  net/sctp/proc.c         |    1 +
>  net/sctp/sm_statefuns.c |    2 ++
>  3 files changed, 4 insertions(+), 0 deletions(-)
> 
> diff --git a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h
> index 65946bc..f7fb5de 100644
> --- a/include/net/sctp/sctp.h
> +++ b/include/net/sctp/sctp.h
> @@ -263,6 +263,7 @@ enum {
>  	SCTP_MIB_IN_PKT_BACKLOG,
>  	SCTP_MIB_IN_PKT_DISCARDS,
>  	SCTP_MIB_IN_DATA_CHUNK_DISCARDS,
> +	SCTP_MIB_HEARTBEAT_EXPIREDS,
>  	__SCTP_MIB_MAX
>  };
>  
> diff --git a/net/sctp/proc.c b/net/sctp/proc.c
> index 5584d1a..53263ca 100644
> --- a/net/sctp/proc.c
> +++ b/net/sctp/proc.c
> @@ -74,6 +74,7 @@ static const struct snmp_mib sctp_snmp_list[] = {
>  	SNMP_MIB_ITEM("SctpInPktDiscards", SCTP_MIB_IN_PKT_DISCARDS),
>  	SNMP_MIB_ITEM("SctpInDataChunkDiscards", SCTP_MIB_IN_DATA_CHUNK_DISCARDS),
>  	SNMP_MIB_ITEM("SctpT1Retransmits", SCTP_MIB_T1_RETRANSMITS),
> +	SNMP_MIB_ITEM("SctpHeartbeatExpireds", SCTP_MIB_HEARTBEAT_EXPIREDS),
>  	SNMP_MIB_SENTINEL
>  };
>  
> diff --git a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c
> index 24b2cd5..8d3e223 100644
> --- a/net/sctp/sm_statefuns.c
> +++ b/net/sctp/sm_statefuns.c
> @@ -974,6 +974,8 @@ sctp_disposition_t sctp_sf_sendbeat_8_3(const struct sctp_endpoint *ep,
>  {
>  	struct sctp_transport *transport = (struct sctp_transport *) arg;
>  
> +	SCTP_INC_STATS(SCTP_MIB_HEARTBEAT_EXPIREDS);
> +
>  	if (asoc->overall_error_count >= asoc->max_retrans) {
>  		sctp_add_cmd_sf(commands, SCTP_CMD_SET_SK_ERR,
>  				SCTP_ERROR(ETIMEDOUT));

Re: [PATCH 3/3] sctp: add heartbeat expired counter to /proc/net/sctp/snmp

[Shan Wei]

Vlad Yasevich wrote, at 07/02/2010 10:38 PM:
> 
> Shan Wei wrote:
>> Just like T4-RTO, T3-RXT timeout events, add HEARTBEAT timeout
>> counter for debug. It is useful because all these timeout events
>> cause association error counter to increase.
>>
> 
> Unlinke T4-RTO and T3-RTO, heartbeat timeouts happen all the time
> and do not necessarily mean that a something is wrong.

They are different. I ignore this. 
 
> It may be worth tracking the number of non-responded heartbeats, since those
> will actually cause association destruction.

If a heartbeat chunk is not responded, the global
error counter value is increased. If this error value exceeds association_max_retrans,
abort the association. But the error counter is also added by T3-RTO, T4-RTO event.

Although we know the number of non-responded heartbeats, we also don't know
the closer of association destruction.

-- 
Best Regards
-----
Shan Wei

Re: [PATCH 3/3] sctp: add heartbeat expired counter to /proc/net/sctp/snmp

[Vlad Yasevich]

Shan Wei wrote:
> Vlad Yasevich wrote, at 07/02/2010 10:38 PM:
>> Shan Wei wrote:
>>> Just like T4-RTO, T3-RXT timeout events, add HEARTBEAT timeout
>>> counter for debug. It is useful because all these timeout events
>>> cause association error counter to increase.
>>>
>> Unlinke T4-RTO and T3-RTO, heartbeat timeouts happen all the time
>> and do not necessarily mean that a something is wrong.
> 
> They are different. I ignore this. 
>  
>> It may be worth tracking the number of non-responded heartbeats, since those
>> will actually cause association destruction.
> 
> If a heartbeat chunk is not responded, the global
> error counter value is increased. If this error value exceeds association_max_retrans,
> abort the association. But the error counter is also added by T3-RTO, T4-RTO event.
> 
> Although we know the number of non-responded heartbeats, we also don't know
> the closer of association destruction.
> 

Correct, but you are still not going to know this if you track the HB timeouts.
T3 and T4 timeouts are rare and signify a problem on the network.  HB timeouts do
not.  The number of HB timeouts on the system will be so large and potentially wrap
so quickly that it will not provide any useful information.

On the other hands, timeouts triggered by a non-responsive HB do have value.  They
indicate a similar problem as T3 and T4 timeouts, i.e the path to the remote end is down.
Keeping that value would provide as much information as the T3 timeout value.

-vlad