> On 16 Jul 2015, at 13:13, Karen Elisabeth Egede Nielsen > <karen.niel...@tieto.com> wrote: > > HI Michael, > >> -----Original Message----- >> From: Michael Tuexen [mailto:michael.tue...@lurchi.franken.de] >> Sent: Thursday, July 16, 2015 12:45 PM >> To: Karen Elisabeth Egede Nielsen >> Cc: Joe Touch; Pal Martinsen (palmarti); taps@ietf.org >> Subject: Re: [Taps] TAPS Transports and ICMP >> >>> On 16 Jul 2015, at 12:26, Karen Elisabeth Egede Nielsen >> <karen.niel...@tieto.com> 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. OK. FreeBSD provides EHOSTUNREACH instead of ETIMEDOUT for TCP. It doesn't support ENETUNREACH. I don't think we do this in SCTP...
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 >>>>>>>> Taps@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/taps >>>>>>> >>>>> >>> > _______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
