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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
