[PATCH RFC] sctp: Update HEARTBEAT timer immediately after user changed HB.interval

For an established association, if user has updated the HB.interval
parameter by setsockopt(), this new heartbeat interval will not
take effect until:
  - the expiry of the heartbeat timer and new hearbeat is sent.
  - DATA chunk has been sent and the transport resets the timer.
This could not meet the requirement of the user who need to
get HEARTBEAT sent at the specified time.

Thus, we need to update the heartbeat timer immediately after
user has changed HB.interval.

Signed-off-by: Xufeng Zhang <redacted>
---
 net/sctp/socket.c |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index 9e91d6e..699ae1e 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c

@@ -2344,6 +2344,11 @@ static int sctp_apply_peer_addr_params(struct sctp_paddrparams *params,
 			if (trans) {
 				trans->hbinterval =
 				    msecs_to_jiffies(params->spp_hbinterval);
+
+				/* Update the heartbeat timer immediately. */
+				if (!mod_timer(&trans->hb_timer,
+					    sctp_transport_timeout(trans)))
+					sctp_transport_hold(trans);
 			} else if (asoc) {
 				asoc->hbinterval =
 				    msecs_to_jiffies(params->spp_hbinterval);

-- 
1.7.0.2

On Tue, Feb 18, 2014 at 01:56:50PM +0800, Xufeng Zhang wrote:

For an established association, if user has updated the HB.interval
parameter by setsockopt(), this new heartbeat interval will not
take effect until:
  - the expiry of the heartbeat timer and new hearbeat is sent.
  - DATA chunk has been sent and the transport resets the timer.
This could not meet the requirement of the user who need to
get HEARTBEAT sent at the specified time.

Thus, we need to update the heartbeat timer immediately after
user has changed HB.interval.

Signed-off-by: Xufeng Zhang <redacted>

Acked-by: Neil Horman <nhorman@tuxdriver.com>

On 02/18/2014 12:56 AM, Xufeng Zhang wrote:

This is causes a rather inconsistent behavior in that it doesn't
account of the amount of time left on the hb timer.  Thus it doesn't
always do what commit log implies.  If the remaining time is shorter
then the new timeout value, it will take longer till the next HB
the application expects.

If the application has very strict timing requirement on the HBs, it
should trigger the HB manually.

We could rework the code to allow the combination of
SPP_HB_DEMAND | SPP_HB_ENABLE to work as follows:
  1) update the timer to the new value
  2) Send an immediate HB
     a) Update the hb timeout.

2a should probably be done regardless since it can cause 2 HB to be
outstanding at the same time.

-vlad

 			} else if (asoc) {
 				asoc->hbinterval =
 				    msecs_to_jiffies(params->spp_hbinterval);

quoted

+
+				/* Update the heartbeat timer immediately. */
+				if (!mod_timer(&trans->hb_timer,
+					    sctp_transport_timeout(trans)))
+					sctp_transport_hold(trans);

This is causes a rather inconsistent behavior in that it doesn't
account of the amount of time left on the hb timer.  Thus it doesn't
always do what commit log implies.  If the remaining time is shorter
then the new timeout value, it will take longer till the next HB
the application expects.

Being able to stop heartbeats being sent by repeatedly configuring
the interval is certainly not a good idea!

If the application has very strict timing requirement on the HBs, it
should trigger the HB manually.

We could rework the code to allow the combination of
SPP_HB_DEMAND | SPP_HB_ENABLE to work as follows:
  1) update the timer to the new value
  2) Send an immediate HB
     a) Update the hb timeout.

2a should probably be done regardless since it can cause 2 HB to be
outstanding at the same time.

Sending a heartbeat 'on demand' might be problematic if one
has also just been sent (from the timer).

I'd have thought that you wouldn't want to send a heartbeat while
still expecting a response from the previous one (this might require
splitting the time interval in two).

	David

On 02/18/2014 10:39 AM, David Laight wrote:

quoted

quoted

+
+				/* Update the heartbeat timer immediately. */
+				if (!mod_timer(&trans->hb_timer,
+					    sctp_transport_timeout(trans)))
+					sctp_transport_hold(trans);

This is causes a rather inconsistent behavior in that it doesn't
account of the amount of time left on the hb timer.  Thus it doesn't
always do what commit log implies.  If the remaining time is shorter
then the new timeout value, it will take longer till the next HB
the application expects.

Being able to stop heartbeats being sent by repeatedly configuring
the interval is certainly not a good idea!

quoted

If the application has very strict timing requirement on the HBs, it
should trigger the HB manually.

We could rework the code to allow the combination of
SPP_HB_DEMAND | SPP_HB_ENABLE to work as follows:
  1) update the timer to the new value
  2) Send an immediate HB
     a) Update the hb timeout.

2a should probably be done regardless since it can cause 2 HB to be
outstanding at the same time.

Sending a heartbeat 'on demand' might be problematic if one
has also just been sent (from the timer).

Yes, you are right.  This will trigger an rto doubling since we'll
be in a state where we have an outstanding HB without an ack.

I'd have thought that you wouldn't want to send a heartbeat while
still expecting a response from the previous one (this might require
splitting the time interval in two).

This one is interesting.  Technically, a user can request an immediate
HB any time, and if the user requests it, we should honor the request.
Also, the user may not know that there is an outstanding HB.  I'll need
to think about this a bit.

Thanks for bringing this up.
-vlad

	David