> On 16 Jul 2015, at 12:26, Karen Elisabeth Egede Nielsen > <[email protected]> wrote: > > HI Michael, >>> >>> [Karen ] This might (the MAY) results in hard trouble if the >>> association is closed due to entering of dormant state. >>> That's why we believe that this MAY reaction should be coupled with >>> robust dormant state handling. >> I think we have to distinguish two things here: >> > [Karen ] Yes, I agree. > >> 1. When you receive an ICMP message you might increment the path error >> counter or change the path state. When changing the path state >> notify the user about it. This is about ICMP handling > [Karen ] > Yes. But user is not notified of the receipt of ICMPs. > > I should perhaps tell that we have some SCTP SW versions that follow the > MAY and others which ignores these > destination unreachable ICMPs. > > 2. Deal with the case >> that all paths are inactive, which means deal >> with the dormant state. This is NOT related to the ICMP handling, >> since it doesn't matter how you end up in the dormant state. >> It might make ending up there more often, but and implementation >> needs to deal with it anyway. >>> >>> However, the user is provided with the >>>> information, if requested, either about an association or path state >>> change. >>> [Karen ] Yes, but the user is not provided with the information that >>> the association was closed due to the receipt ICMPs. >> Correct. But does the application care if the peer sent an ABORT or an > ICMP >> Destination unreachable? > > [Karen ] For TCP the socket api provides the information. How? Isn't it the same as for SCTP? A system call returns -1 and errno is set to some value line ECONNRESET or ECONNREFUSED? I think the user can't distinguish from receiving an TCP RST. Am I missing something? > Presumably this is because the application could care. > For implementations that do the "suboptimal" dormant state handling and > follow the MAY here, then > an application would care, I think. > >> I don't think so. And I think both cases are signalled >> to the application for TCP in the same way. >>> [Karen ] Yes, but even if the information is provided, then closing >>> the association does not constitute a soft reaction. >> ICMP9) of https://tools.ietf.org/html/rfc4960#appendix-C tells you that > it is >> OK to increment the error counter or mark the destination as unreachable. > It >> is up to you to decide what is appropriate in your implementation. > However, >> you should not increment the association error counter, so it shouldn't > be an >> association failure. > [Karen ] I agree. >> An association failure can only occur if you move the path state to >> unreachable, have no reachable destinations anymore (dormant state) and >> have decided that this means failing the association. But again, this is > related >> to an, in my view, suboptimal handling of the dormant state. FreeBSD > doesn't >> fail the association in this case. > [Karen ] I agree that this is suboptimal handling of dormant state. We > also do not to this suboptimal handling. > I think that one could say that RFC4960 Appendix C prescriptions for how > to handle soft icmps could relate to that this can make the assocs enter > dormant state fast and that dormant state implementation > need to relate to this fact if the MAYs are followed. OK.
Best regards Michael > > BR, Karen >> >> Best regards >> Michael >>> >>> BR, Karen >>>> >>>> Best regards >>>> Michael >>>>> >>>>>> In particular, destination unreachables can cause the SCTP >>>>>> connection to >>>>> go >>>>> [Karen ] MAY force. And this MAY of the RFC I (and we) believe is >>>>> questionable. We believe that for an implementation to support this >>>>> MAY the implementation MUST implement dormant state handling as >>>>> described (right now) in the SCTP Failover draft = SCTP continues to >>>>> transmit data also when the destinations are considered unreachable. >>>>> (and our SCTP implementations do this). Further we think that the >>>>> appropriate soft reaction to ICMP destination unreachable is to >>>>> increment the path error counter, NOT to mark the destination as >>>>> INACTIVE. >>>>> Hopefully we will see these things be clarified in future SCTP >>>>> drafts or ideally in the eventual RFC4960 revision. >>>>> >>>>>> into a dead state (mark the dest unreachable or increment the path >>>>>> error >>>>>> counter) without indicating anything to the user. >>>>>> >>>>> [Karen ] The state is not dead if "appropriate" dormant state >>>>> handling is implemented. >>>>> >>>>>> This seems incorrect to me, given the number of other ways in which >>>>>> SCTP >>>>> can >>>>>> shut down a connection (heartbeat failure, retransmission failre) >>>>>> and is supposed to pass that info to the user. >>>>>> >>>>> [Karen ] I agree that when the association is closed as a direct >>>>> result of receipt of ICMPs then this should be communicated to the >>> Users. >>>>> The envisaged approach (from our side) is to define a new error code >>>>> for the sac_error of the SCTP_ASSOC_CHANGE (the notification of >>>> comm_LOST): >>>>> >>>>> sac_error: If the state was reached due to an error condition > (e.g., >>>>> SCTP_COMM_LOST), any relevant error information is available in >>>>> this field. This corresponds to the protocol error codes defined >>>>> in [RFC4960]. >>>>> >>>>> Right now we have the possibility to use proprietary error codes >>>>> here, but we would like to go beyond that of course. >>>>> >>>>> For the destination error counter the information goes into the >>>>> spc_error of the SCTP_PEER_ADDR_CHANGE (the notification of >>>>> destination address unreachability). >>>>> >>>>> PLEASE allow me to explain the abstract API in terms of a concrete >>>>> one. I do understand the difference. >>>>> The new thing is that the abstract transport API, which if nothing >>>>> else exists in our heads and in our overall modeling, now with TAPS, >>>>> may be defined as a concrete one. >>>>> And I agree with everybody else that this is a good exercise and >>>>> that it is doomed to (correct and) improve things substantially. >>>>> >>>>>> So, IMO, this is a great example of why studying these APIs as >>>>> abstractions is >>>>>> important and would have prevented this (IMO) oversight. >>>>> [Karen ] We have studied this. But is only bringing this to the IETF >>> now. >>>>> Possibly to be addressed for RFC4960 revision. >>>>>> >>>>>> Or can someone in the SCTP team explain why shutting connections >>>>>> down due to other reasons is a user signal but validated ICMP >>>>>> signals are >>> not? >>>>> [Karen ] NA. >>>>>> >>>>>> Joe >>>>>> >>>>>> _______________________________________________ >>>>>> Taps mailing list >>>>>> [email protected] >>>>>> https://www.ietf.org/mailman/listinfo/taps >>>>> >>> > _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
