Subject: [tsvwg] Proposal for socket api extension for PFAILED notification

From: "Karen E. Egede Nielsen" <[email-masked]>
Date: Mon, 4 Nov 2013 08:15:01 -0800

Hi,

For an RFC4960 SCTP implementation UNREACHABLE event notification on the
(current) Primary Path serves to tell UL of leave of the (current)

Primary Path. With introduction of the Potentially Failed state in the
quick failover function of SCTP, no such event may be generated.

It is true that there is a “made primary” event, which indirectly tell of
change of primary path, but some SCTP implementation defer the generation
of this event

until a new proven working primary path has been located (or set).

To cater for event notification of the PFAILED state, the following
optional extension to the socket api is proposed:

New SCTP event type is defined. I.e., new se_type of RFC6458.

Proposed name: SCTP_PEER_ADDR_CHANGE_EXT_PF.

New spc_state is defined. Proposed name SCTP_ADDR_PFAILED: The address
specified is Potentially Failed.

When the SCTP_PEER_ADDR_CHANGE_EXT_PF event is subscribed to by UL, UL

will by means of the existing  sctp_paddr_change notification structure receive
notification of the

following state transitions of a destination address:

ACTIVE à PFAILED : spc_state= SCTP_ADDR_PFAILED

PFAILED à ACTIVE: spc_state = SCTP_ADDR_AVAILABLE

The proposal is backward compatible and it allows ULs who want to ignore
the PFAILED events to not

receive them. ULs which do not want to receive the above listed state
transitions will subscribe only to existing SCTP_PEER_ADDR_CHANGE event.

An alternative approach (less preferred from my perspective) is to
implement the event notification as non-optional.

Meaning that once the PFAILED function is enabled then the above described
events will be generated as soon as UL subscribe to

existing SCTP_PEER_ADDR_CHANGE event.

BR, Karen

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 4 Nov 2013 10:50:08 -0800

On Nov 4, 2013, at 8:15 AM, Karen E. Egede Nielsen <[email-masked]> wrote:

> Hi,
>  
> For an RFC4960 SCTP implementation UNREACHABLE event notification on the (current) Primary Path serves to tell UL of leave of the (current)
> Primary Path. With introduction of the Potentially Failed state in the quick failover function of SCTP, no such event may be generated.
>  
> It is true that there is a “made primary” event, which indirectly tell of change of primary path, but some SCTP implementation defer the generation of this event
I think the semantic of the event is that it is sent, when a new primary path is set by
the kernel. This can happen, because:
* The peer requests this by using ASCONF.
* The kernel decides that it has to change the primary path.
>  
> To cater for event notification of the PFAILED state, the following optional extension to the socket api is proposed:
>  
> New spc_state is defined. Proposed name SCTP_ADDR_PFAILED: The address specified is Potentially Failed.
Hmm. What about SCTP_ADDR_POTENTIALLY_FAILED or SCTP_ADDR_POT_FAILED.
> will by means of the existing  sctp_paddr_change notification structure receive notification of the
> The proposal is backward compatible and it allows ULs who want to ignore the PFAILED events to not
> receive them. ULs which do not want to receive the above listed state transitions will subscribe only to existing SCTP_PEER_ADDR_CHANGE event.
>  
> An alternative approach (less preferred from my perspective) is to implement the event notification as non-optional.
> Meaning that once the PFAILED function is enabled then the above described events will be generated as soon as UL subscribe to
Adding a new event type just for adding a new path state seems to be pretty invasive. I could live with it,
but I would prefer just to extend SCTP_PEER_ADDR_CHANGE.

Just my thought...

Best regards
Michael

---

From: "Karen E. Egede Nielsen" <[email-masked]>
Date: Mon, 4 Nov 2013 13:55:15 -0800

Hi Michael,

Thanks a lot for your feedback :-)

> I think the semantic of the event is that it is sent, when a new primary
path is
> set by the kernel. This can happen, because:
[Karen] In a standard RFC4960 switchback scenario SCTP, e.g. FreeBSD SCTP,
would not generate this event for an alternative path in case
 SCTP temporarily was using this alternative path for data transfer as the
Primary Path has entered Potentially Failed state - Correct ?

> > To cater for event notification of the PFAILED state, the following
optional
> extension to the socket api is proposed:
> >
[Karen] I am very fine with both. I tend to like the first a little better
than the second.
> > will by means of the existing  sctp_paddr_change notification
> > structure receive notification of the following state transitions of a
> destination address:
> > ACTIVE à PFAILED : spc_state= SCTP_ADDR_PFAILED PFAILED à ACTIVE:
> > spc_state = SCTP_ADDR_AVAILABLE
> >
> > The proposal is backward compatible and it allows ULs who want to
> > ignore the PFAILED events to not receive them. ULs which do not want
to
> receive the above listed state transitions will subscribe only to
existing
> SCTP_PEER_ADDR_CHANGE event.
> >
> > Meaning that once the PFAILED function is enabled then the above
> > described events will be generated as soon as UL subscribe to existing
> SCTP_PEER_ADDR_CHANGE event.
> Adding a new event type just for adding a new path state seems to be
pretty
> invasive. I could live with it, but I would prefer just to extend
> SCTP_PEER_ADDR_CHANGE.
>
[Karen]
I have a preference for the optional solution both from a
backward compatible as well as from a functional perspective,
but I will be reasonable content also with the non-optional solution.

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 4 Nov 2013 15:18:15 -0800

> Primary Path has entered Potentially Failed state - Correct ?
In the FreeBSD implementation when the primary path becomes UNREACHABLE,
it stays to be primary, but we send data on another patch. Once the primary
patch becomes REACHABLE again, it will be used for data transmission.
Since we don't change the primary path (it just moves from REACHABLE
to UNREACHABLE to REACHABLE), we don't issue the event.
However, other implementations might change the primary path. Then
I would expect them to issue the event.
So, I think you are correct.
> [Karen] I am very fine with both. I tend to like the first a little better
OK. Choice made... Lets use SCTP_ADDR_POTENTIALLY_FAILED.

---

From: Randy Stewart <[email-masked]>
Date: Mon, 4 Nov 2013 15:21:03 -0800

I also agree with Michael here. We really
should not add a duplicate API with only the difference
being a different state number (PF).. I would much rather
see one more state defined for the existing notification.

R

> existing SCTP_PEER_ADDR_CHANGE event.

-----
Randall Stewart
[email-masked]