Re: [Taps] TAPS Transports and ICMP
Michael Tuexen <Michael.Tuexen@lurchi.franken.de> Thu, 16 July 2015 10:45 UTC
Return-Path: <Michael.Tuexen@lurchi.franken.de>
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4021B38E5 for <taps@ietfa.amsl.com>; Thu, 16 Jul 2015 03:45:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.561
X-Spam-Level:
X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WldgwmSrKyZ7 for <taps@ietfa.amsl.com>; Thu, 16 Jul 2015 03:45:31 -0700 (PDT)
Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 599C51A8833 for <taps@ietf.org>; Thu, 16 Jul 2015 03:45:31 -0700 (PDT)
Received: from [192.168.1.200] (p4FE31B43.dip0.t-ipconnect.de [79.227.27.67]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 0C42B1C0C0BCE; Thu, 16 Jul 2015 12:45:28 +0200 (CEST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <a1df9182e9562fe6dc1bb0613ff2279c@mail.gmail.com>
Date: Thu, 16 Jul 2015 12:45:27 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <C331AA76-0A10-4DB6-A430-12530F735EAB@lurchi.franken.de>
References: <00597CB8-D128-408A-8F35-BA98CDF45A62@cisco.com> <55707211.8010609@isi.edu> <26B9DE0B-4D38-430D-A9A1-921CD0067C70@cisco.com> <5570988A.6040208@isi.edu> <97FD8853-7345-40E9-A523-8AF53FB2303B@lurchi.franken.de> <2b5eb97add78e6c5b3c91b94080479da@mail.gmail.com> <55A6A53C.3010009@isi.edu> <b12ebf1f4f628e0cc38787a035ac0b92@mail.gmail.com> <86015ACB-0C19-41CF-B16E-765DD5DD29A6@lurchi.franken.de> <cd67801fe4dc3a5b37e382d58c0ce58d@mail.gmail.com> <5CFFB56C-9C2D-4E27-BF39-FA2D5982749E@lurchi.franken.de> <a1df9182e9562fe6dc1bb0613ff2279c@mail.gmail.com>
To: Karen Elisabeth Egede Nielsen <karen.nielsen@tieto.com>
X-Mailer: Apple Mail (2.2102)
Archived-At: <http://mailarchive.ietf.org/arch/msg/taps/SlZ12sU50gMfzq2r25nxhOZRZRg>
Cc: "Pal Martinsen (palmarti)" <palmarti@cisco.com>, taps@ietf.org, Joe Touch <touch@isi.edu>
Subject: Re: [Taps] TAPS Transports and ICMP
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussions on Transport Services <taps.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/taps>, <mailto:taps-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/taps/>
List-Post: <mailto:taps@ietf.org>
List-Help: <mailto:taps-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/taps>, <mailto:taps-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Jul 2015 10:45:36 -0000
> On 16 Jul 2015, at 12:26, Karen Elisabeth Egede Nielsen <karen.nielsen@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? 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 >>>>>> Taps@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/taps >>>>> >>> >
- [Taps] TAPS Transports and ICMP Pal Martinsen (palmarti)
- Re: [Taps] TAPS Transports and ICMP Joe Touch
- Re: [Taps] TAPS Transports and ICMP Pal Martinsen (palmarti)
- Re: [Taps] TAPS Transports and ICMP Joe Touch
- Re: [Taps] TAPS Transports and ICMP Pal Martinsen (palmarti)
- Re: [Taps] TAPS Transports and ICMP Joe Touch
- Re: [Taps] TAPS Transports and ICMP Michael Tuexen
- Re: [Taps] TAPS Transports and ICMP Pal Martinsen (palmarti)
- Re: [Taps] TAPS Transports and ICMP Joe Touch
- Re: [Taps] TAPS Transports and ICMP Michael Tuexen
- Re: [Taps] TAPS Transports and ICMP Pal Martinsen (palmarti)
- Re: [Taps] TAPS Transports and ICMP Joe Touch
- Re: [Taps] TAPS Transports and ICMP Karen Elisabeth Egede Nielsen
- Re: [Taps] TAPS Transports and ICMP Joe Touch
- Re: [Taps] TAPS Transports and ICMP Karen Elisabeth Egede Nielsen
- Re: [Taps] TAPS Transports and ICMP Michael Tuexen
- Re: [Taps] TAPS Transports and ICMP Michael Tuexen
- Re: [Taps] TAPS Transports and ICMP Karen Elisabeth Egede Nielsen
- Re: [Taps] TAPS Transports and ICMP Michael Tuexen
- Re: [Taps] TAPS Transports and ICMP Karen Elisabeth Egede Nielsen
- Re: [Taps] TAPS Transports and ICMP Michael Tuexen
- Re: [Taps] TAPS Transports and ICMP Karen Elisabeth Egede Nielsen
- Re: [Taps] TAPS Transports and ICMP Michael Tuexen
- Re: [Taps] TAPS Transports and ICMP Joe Touch
- Re: [Taps] TAPS Transports and ICMP Joe Touch
- Re: [Taps] TAPS Transports and ICMP Joe Touch
- Re: [Taps] TAPS Transports and ICMP Joe Touch
- Re: [Taps] TAPS Transports and ICMP Karen Elisabeth Egede Nielsen