From: Neil Horman <nhorman@tuxdriver.com>

Sent: 14 October 2019 13:42
To: Xin Long <lucien.xin@gmail.com>
Cc: David Laight <redacted>; network dev <redacted>; linux-sctp@vger.kernel.org; Marcelo
Ricardo Leitner [off-list ref]; davem@davemloft.net
Subject: Re: [PATCHv2 net-next 3/5] sctp: add SCTP_EXPOSE_POTENTIALLY_FAILED_STATE sockopt

On Mon, Oct 14, 2019 at 04:36:34PM +0800, Xin Long wrote:

quoted

On Thu, Oct 10, 2019 at 12:18 AM Neil Horman [off-list ref] wrote:

quoted

On Tue, Oct 08, 2019 at 11:28:32PM +0800, Xin Long wrote:

quoted

On Tue, Oct 8, 2019 at 9:02 PM David Laight [off-list ref] wrote:

quoted

From: Xin Long

quoted

Sent: 08 October 2019 12:25

This is a sockopt defined in section 7.3 of rfc7829: "Exposing
the Potentially Failed Path State", by which users can change
pf_expose per sock and asoc.

If I read these patches correctly the default for this sockopt in 'enabled'.
Doesn't this mean that old application binaries will receive notifications
that they aren't expecting?

I'd have thought that applications would be required to enable it.

If we do that, sctp_getsockopt_peer_addr_info() in patch 2/5 breaks.

I don't think we can safely do either of these things.  Older
applications still need to behave as they did prior to the introduction
of this notification, and we shouldn't allow unexpected notifications to
be sent.

Hi, Neil

I think about again, and also talked with QE, we think to get unexpected
notifications shouldn't be a problem for user's applications.

On principle, I disagree.  Regardless of what the RFC does, we shouldn't
send notifications that an application aren't subscribed to.  Just
because QE doesn't think it should be a problem (and for their uses it
may well not be an issue), we can't make that general assumption.

quoted

RFC actually keeps adding new notifications, and a user shouldn't expect
the specific notifications coming in some exact orders. They should just
ignore it and wait until the ones they expect. I don't think some users
would abort its application when getting an unexpected notification.

To make that assertion is to discount the purpose of the SCTP_EVENTS
sockopt entirely.  the SCTP_EVENTS option is a whitelist operation, so
they expect to get what they subscribe to, and no more.

quoted

We should NACK patchset v3 and go with v2. What do you think?

No, we need to go with an option that maintains backwards compatibility
without relying on the assumption that applications will just ignore
events they didn't subscribe to.  Davids example is a case in point.

Although I don't enable the SCTP_PEER_ADDR_CHANGE indications.
But rfc 6458 doesn't say that the list might be extended.

Aren't there 3 separate items here:
1) The SCTP protocol changes (to better handle primary path failure).
2) The SCTP_GET_PEER_ADDR_INFO sockopt.
3) The MSG_NOTIFICATION indication for SCTP_ADDR_POTENTIALLY_FAILED.

Looking at RFC 7829 section 7.3.
7.3 defines SCTP_EXPOSE_POTENTIALLY_FAILED_STATE.
For compatibility this must default to 'disabled'.
This is even true if the application has set the SCTP_PEER_ADDR_THLDS.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)