From: zhuyj <zyjzyj2000@gmail.com>
To: LKML <linux-kernel@vger.kernel.org>,
netdev <netdev@vger.kernel.org>,
Vlad Yasevich <vyasevich@gmail.com>,
tuexen@fh-muenster.de, khandelwal.deepak.1987@gmail.com, "Tao,
Yue" <Yue.Tao@windriver.com>,
Alexandre Dietsch <alexandre.dietsch@windriver.com>,
"David S. Miller" <davem@davemloft.net>,
zhuyj <zyjzyj2000@gmail.com>
Subject: Re: SCTP_PEER_ADDR_CHANGE Notification over UNCONFIRMED path
Date: Fri, 15 Aug 2014 17:32:41 +0800 [thread overview]
Message-ID: <53EDD3B9.9070301@gmail.com> (raw)
In-Reply-To: <53EDC9AA.9080500@gmail.com>
Sorry. I used attachment to send patch. Maybe it is not convenient. Now
I resend it again. Please ignore this mail.
Best Regards!
Zhu Yanjun
On 08/15/2014 04:49 PM, zhuyj wrote:
> 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
prev parent reply other threads:[~2014-08-15 9:32 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-15 8:49 SCTP_PEER_ADDR_CHANGE Notification over UNCONFIRMED path zhuyj
2014-08-15 9:32 ` zhuyj [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53EDD3B9.9070301@gmail.com \
--to=zyjzyj2000@gmail.com \
--cc=Yue.Tao@windriver.com \
--cc=alexandre.dietsch@windriver.com \
--cc=davem@davemloft.net \
--cc=khandelwal.deepak.1987@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=tuexen@fh-muenster.de \
--cc=vyasevich@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.