Hi Michael, >> [Karen ] TCP maps the received soft destination unreachable ICMPs to >> ENETUNREACH or EHOSTUNREACH pending errors on socket. >OK. FreeBSD provides EHOSTUNREACH instead of ETIMEDOUT for TCP. >It doesn't support ENETUNREACH. I don't think we do this in SCTP... > [Karen ] Yes. We do this for TCP (it is from rfc1122 I think), but not for SCTP and it is not prescribed in RFC6458 or RFC4960 for SCTP. This was the point of the notification discussion.
Ideally I would like to see: * Path Failure and Assoc Change Event error fields are extended with new error value to be given when change is direct results of a received ICMP - and the ICMP should then also be passed up. NICE (or NOT NICE ?): * Generally then receipt of ICMPs results in notifications (if notifications are subscribed for of course). I am not so sure about the second as the notifications fills and take resources - and this is soft ICMPs. We have first and foremost focused on the first. BR, Karen >Best regards >Michael >> Thus at least temporarily this information is available and is >> notified towards the user. >> True that when the connection is closed, the information is >> overwritten - unless multiple pending errors are maintained by the >implementation. >> >>> 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. >> [Karen ] Thanks for understanding. >> >> BR, Karen >>> >>> 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
