HI Michael, >-----Original Message----- >From: Michael Tuexen [mailto:[email protected]] >Sent: Thursday, July 16, 2015 12:45 PM >To: Karen Elisabeth Egede Nielsen >Cc: Joe Touch; Pal Martinsen (palmarti); [email protected] >Subject: Re: [Taps] TAPS Transports and ICMP > >> 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?
[Karen ] TCP maps the received soft destination unreachable ICMPs to ENETUNREACH or EHOSTUNREACH pending errors on socket. 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
