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
>>>>> 
>>> 
>