Re: [Taps] TAPS Transports and ICMP

[Michael Tuexen <[e-mail]>]

> On 16 Jul 2015, at 13:13, Karen Elisabeth Egede Nielsen <[e-mail]> wrote:
> 
> HI Michael,
> 
>> -----Original Message-----
>> From: Michael Tuexen [mailto:[e-mail]]
>> Sent: Thursday, July 16, 2015 12:45 PM
>> To: Karen Elisabeth Egede Nielsen
>> Cc: Joe Touch; Pal Martinsen (palmarti); [e-mail]
>> Subject: Re: [Taps] TAPS Transports and ICMP
>> 
>>> On 16 Jul 2015, at 12:26, Karen Elisabeth Egede Nielsen
>> <[e-mail]> 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
>>>>>>>> [e-mail]
>>>>>>>> https://www.ietf.org/mailman/listinfo/taps
>>>>>>> 
>>>>> 
>>> 
>