From patchwork Fri Aug 15 08:49:46 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Zhu Yanjun X-Patchwork-Id: 380125 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 9A2E614008C for ; Fri, 15 Aug 2014 18:50:27 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752247AbaHOIuE (ORCPT ); Fri, 15 Aug 2014 04:50:04 -0400 Received: from mail-pa0-f43.google.com ([209.85.220.43]:62933 "EHLO mail-pa0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751272AbaHOIuB (ORCPT ); Fri, 15 Aug 2014 04:50:01 -0400 Received: by mail-pa0-f43.google.com with SMTP id lf10so3148083pab.2 for ; Fri, 15 Aug 2014 01:49:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type; bh=HdsAglgOvAa5zEkefpXINEfNOdUeG/z2vjffbrLOIrs=; b=JNaQzsvMgc1R480/UxCe7lTnKiOa11/NLSqa0/nXtshxxUtTXlvQxSE7Y1uj9WQvQE kQcZ43YC6LB3mw4Zh51WEFnHcSE/UMpu1npR2HaX/FjUNQkmfG3UqPP942KuP5sp7n0Q u3BkUxs8flLIDkx7cdTduTisV5fO3v1Wk7Lf5ORG/cjLcSBgg3vF3yT4uZmQBiaBudOh cYZvvM25ejsjjZ1gykWifdppRKIaFU2dS/kTpf5mISUQuewz+zckjBW6gdpsZuusO32X ttKiQ+3yux3iyQjP4M4p/hsKCdGTqFEA+eb26YePXF/CXh1dAmdysS2bmWv0XpNIxPHl KDVw== X-Received: by 10.68.132.10 with SMTP id oq10mr10558399pbb.132.1408092594507; Fri, 15 Aug 2014 01:49:54 -0700 (PDT) Received: from [128.224.162.201] ([1.202.252.122]) by mx.google.com with ESMTPSA id ey10sm11163796pdb.50.2014.08.15.01.49.49 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Aug 2014 01:49:53 -0700 (PDT) Message-ID: <53EDC9AA.9080500@gmail.com> Date: Fri, 15 Aug 2014 16:49:46 +0800 From: zhuyj User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: LKML , netdev , Vlad Yasevich , tuexen@fh-muenster.de, khandelwal.deepak.1987@gmail.com, "Tao, Yue" , Alexandre Dietsch , "David S. Miller" , zhuyj Subject: SCTP_PEER_ADDR_CHANGE Notification over UNCONFIRMED path Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Hi, Vlad && DEEPAK && Michael && David From Michael && DEEPAK " lxr SCTP implementation, doesn't transit the path state to INACTIVE, if it was never confirmed. this leads to SCTP_PEER_ADDRESS_CHANGE notification after each failed probe from this time. Is there any specific reason to have same notification to SCTP User with each probe in RTO time period ? 806 case SCTP_TRANSPORT_DOWN: 807 /* If the transport was never confirmed, do not transition it 808 * to inactive state. Also, release the cached route since 809 * there may be a better route next time. 810 */ 811 if (transport->state != SCTP_UNCONFIRMED) 812 transport->state = SCTP_INACTIVE; http://lxr.free-electrons.com/source/net/sctp/associola.c#L806 we checked RFC and here it is mentioned as Path Verification Section(5.4) of RFC 4960 http://tools.ietf.org/html/rfc4960 In each RTO, a probe may be sent on an active UNCONFIRMED path in an attempt to move it to the CONFIRMED state. If during this probing the path becomes inactive, this rate is lowered to the normal HEARTBEAT rate. At the expiration of the RTO timer, the error counter of any path that was probed but not CONFIRMED is incremented by one and subjected to path failure detection, as defined in Section 8.2 . When probing UNCONFIRMED addresses, however, the association overall error counter is not incremented Does this mean that in attempt to move a UNCONFIRMED path to CONFIRMED State, the path can become INACTIVE, when transport error counter reaches to path_max_retrans counter ? I would say that the path stays UNCONFIRMED. I would also only expect a SCTP_PEER_ADDRESS_CHANGE notification when a path state changes, not on every try. " I made a patch to disable sending SCTP_PEER_ADDRESS_CHANGE notification every try. Now the patch is in the attachment. Please check it. Zhu Yanjun From 78027ced63911229092c345dbac47c385259fe35 Mon Sep 17 00:00:00 2001 From: Zhu Yanjun Date: Fri, 15 Aug 2014 16:32:51 +0800 Subject: [PATCH 1/1] sctp: not send SCTP_PEER_ADDR_CHANGE notifications with failed probe When a failed probe comes along UNCONFIRMED path, it is not necessary to send SCTP_PEER_ADDR_CHANGE notification. Reported-by: DEEPAK KHANDELWAL Suggested-by: Vlad Yasevich Suggested-by: Michael Tuexen Signed-off-by: Zhu Yanjun --- net/sctp/associola.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/sctp/associola.c b/net/sctp/associola.c index 9de23a2..2e23f6b 100644 --- a/net/sctp/associola.c +++ b/net/sctp/associola.c @@ -813,6 +813,7 @@ void sctp_assoc_control_transport(struct sctp_association *asoc, else { dst_release(transport->dst); transport->dst = NULL; + ulp_notify = false; } spc_state = SCTP_ADDR_UNREACHABLE; -- 1.9.1