Subject: Re: [Taps] TAPS Transports and ICMP

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Wed, 15 Jul 2015 13:16:45 +0200

>-----Original Message-----
>From: Taps [mailto:[email-masked]] On Behalf Of Michael Tuexen
>Sent: Thursday, June 04, 2015 9:20 PM
>To: Joe Touch
>Cc: Pal Martinsen (palmarti); [email-masked]
>Subject: Re: [Taps] TAPS Transports and ICMP
>
>> On 04 Jun 2015, at 20:27, Joe Touch <[email-masked]> wrote:
>>
>>
>>
>> On 6/4/2015 11:15 AM, Pal Martinsen (palmarti) wrote:
>>>
>>>> On 04 Jun 2015, at 17:43, Joe Touch <[email-masked]
>>>> <mailto:[email-masked]>> wrote:
>>>>
>>>>
>>>>
>>>> On 6/4/2015 3:48 AM, Pal Martinsen (palmarti) wrote:
>>>> ...
>>>>> Does it make sense for the TAPS transports draft to add ICMP?
>>>>
>>>> ICMP is not a transport protocol.
>>>
>>> Sure. And I agree. But it has the potential to influence how the various
>>> transport protocols behave. That interaction might be nice to have
>>> described in the transports draft.
>>
>> Abstract APIs need to be described. These are part of that description.
>>
>>>> The ways in which transport protocols either terminate or pass-through
>>>> ICMP messages is part of the transport protocol abstract API.
>>>>
>>>> E.g., for UDP and TCP see RFC1122.
>>>>
>>>> UDP passes all ICMP messages to the app.
>>>>
>>> No. Not unless the application specifically listens for it.
>>
>> UDP passes all ICMP messages to the app. If the app doesn't listen for
>> it, that's the app's decision.
>>
>>> Unfortunately how to do this varies from OS to OS:
>>> See https://tools.ietf.org/html/draft-martinsen-tram-stuntrace-
>01#appendix-A.2 for
>>> examples.
>>
>> You are confusing the OS and language-dependent implementation of the
>> API with the abstract API.
>>
>> RFC1122 requires that UDP implementations make the ICMP signals
>> available to the application. It does not indicate by what mechanism.
>>
>>> Listening for port unreachable can be nice to avoid spamming a host or
>>> application that recently crashed. Detecting fragmentation or max MTU is
>>> also a nice feature especially VoIP applications sending video can
>>> utilise to optimise their packet sizes.
>>
>> UDP is required to pass ALL ICMP messages to the app layer, as per RFC
>1122.
>>
>>>> TCP passes only dest unreachable types 0, 1, and 5, time exceeded and
>>>> parameter problem. All others it interprets or ignores internally and
>>>> it’s not clear it should pass up to the app.
>>>
>>> That is exactly that kind of information I would find useful in the
>>> transports draft.
>>
>> Well, yes - IMO, that's because it's part of the abstract API.
>>
>>> Any pitfalls with ICMP when doing SCTP?
>>
>> In many ways, SCTP subsumes similar requirements as TCP, but that's
>> probably buried in the SCTP docs.
>It is. See
>https://tools.ietf.org/html/rfc4960#appendix-C
>

[Karen ] In this context then it is noteworthy to observe that SCTP defacto
API (spec or implementations, I know)
does not prescribe for that the SCTP transport passes information of
received ICMP messages (any kind/type/code) up to SCTP User.
Here SCTP is significantly different from UDP and TCP defacto APIs.

For security reasons SCTP  demands for hard reaction to receipt of protocol
unreachable,
but that is a protocol feature not an api issue.

BR, Karen

>Best regards
>Michael
>>
>> Joe
>>
>> _______________________________________________
>> Taps mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/taps
>
>_______________________________________________
>Taps mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/taps

---

From: Joe Touch <[email-masked]>
Date: Wed, 15 Jul 2015 11:23:56 -0700

On 7/15/2015 4:16 AM, Karen Elisabeth Egede Nielsen wrote:
...
> but that is a protocol feature not an api issue.

Agreed, however the other ways that SCTP doesn't pass validated ICMPs to
the user seems like a mistake to me.

In particular, destination unreachables can cause the SCTP connection to
go into a dead state (mark the dest unreachable or increment the path
error counter) without indicating anything to the user.

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.

So, IMO, this is a great example of why studying these APIs as
abstractions is important and would have prevented this (IMO) oversight.

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?

Joe

---

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Thu, 16 Jul 2015 09:01:10 +0200

HI Joe,

I generally agree with your comments, but the situations is not
necessarily as bad as you say.
Please see below.

BR, Karen

>From: Taps [mailto:[email-masked]] On Behalf Of Joe Touch
>Sent: Wednesday, July 15, 2015 8:24 PM
>To: Karen Elisabeth Egede Nielsen; Michael Tuexen
>Cc: Pal Martinsen (palmarti); [email-masked]; [email-masked]
>> [Karen ] In this context then it is noteworthy to observe that SCTP
>> defacto API (spec or implementations, I know) does not prescribe for
>> that the SCTP transport passes information of received ICMP messages
>> (any kind/type/code) up to SCTP User.
>> For security reasons SCTP  demands for hard reaction to receipt of
>> protocol unreachable, but that is a protocol feature not an api issue.
>
[Karen ] I agree and we have for our SW recently discussed as to whether
we should implement such notification following
the UDP and TCP semantics. But at present none of our applications has the
need (on why that is, see below).

>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.
>due to other reasons is a user signal but validated ICMP signals are not?
[Karen ] NA.

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 16 Jul 2015 10:49:23 +0200

> On 16 Jul 2015, at 09:01, Karen Elisabeth Egede Nielsen <[email-masked]> wrote:
> 
> HI Joe,
> 
Hi Karen,

can you elaborate what ICMP related information you provide for TCP?

My understanding is that if you follow
https://tools.ietf.org/html/rfc1122#section-4.2.3.9
and ignore Source Quench as specified in
https://tools.ietf.org/html/rfc6633
you end up honouring Destination Unreachable (protocol unreachable,
port unreachable or fragmentation needed and DF set). I guess you
can handle this similar to an TCP RST in the API.
Note: Not sure why "fragmentation needed and DF" SHOULD result in an
abort. I would just use the information or PMTUD...
I'm not sure how you expose Net unreachable, host unreachable or source
route failed in the API. I think the sockets API doesn't do this.

For SCTP, the port unreachable is ignored and for the protocol unreachable
it is a MUST abort. For the Net unreachable, host unreachable you might
use this to indicate some soft error. However, the user is provided with
the information, if requested, either about an association or path state
change.

Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 16 Jul 2015 10:56:14 +0200

> On 15 Jul 2015, at 20:23, Joe Touch <[email-masked]> wrote:
> 
> 
> 
Can you say specifically, what has been missed?

My understanding is that SCTP and TCP are similar in respect to ICMP processing
with the difference that
(a) SCTP ignore ICMP destination unreachable, port unreachable
(b) SCTP requires (MUST instead of SHOULD for TCP) the handling of an ICMP
    destination unreachable, protocol unreachable similar to an SCTP ABORT.
The reason is that there are no legacy SCTP stacks sending ICMP destination unreachable,
port unreachable, so (a) is appropriate. (b) is for protecting hosts that don't
support SCTP.

The "handle like an ABORT" includes notifying the application.

The handling of ICMP Destination unreachable (host or network unreachable)
is similar to the TCP case. If there is an SCTP state change, the user
will be notified if requested.

Best regards
Michael

---

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Thu, 16 Jul 2015 11:09:47 +0200

HI Michael,

>>> Agreed, however the other ways that SCTP doesn't pass validated ICMPs
>>> to the user seems like a mistake to me.
>>>
>> [Karen ] I agree and we have for our SW recently discussed as to
>> whether we should implement such notification following the UDP and
>> TCP semantics. But at present none of our applications has the need
>> (on why that is, see below).
>Hi Karen,
>
[Karen ] We provide information about received destination unreachable
ICMPs to users via socket api.
The same we do for (connected) UDP.

This we could also do for SCTP, but as said we don't do it (yet).

>you end up honouring Destination Unreachable (protocol unreachable, port
>unreachable or fragmentation needed and DF set). I guess you can handle
this
>similar to an TCP RST in the API.
>For SCTP, the port unreachable is ignored and for the protocol
unreachable it
>is a MUST abort. For the Net unreachable, host unreachable you might use
>this to indicate some soft error.

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

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.
[Karen ] Yes, but even if the information is provided, then closing the
association does not constitute a soft reaction.

BR, Karen
>> questionable.  We believe that for an implementation to support this
>> MAY the implementation MUST implement dormant state handling as
>> 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.
>>
>> [Karen ] The state is not dead if "appropriate" dormant state handling
>> is implemented.
>>
>>> 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):
>>
>> 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.
>>

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 16 Jul 2015 11:40:32 +0200

> On 16 Jul 2015, at 11:09, Karen Elisabeth Egede Nielsen <[email-masked]> wrote:
> 
> HI Michael,
> 
OK. FreeBSD does this. So it is not an issue with the specification,
but an implementation issue.
> That's why we believe that this MAY reaction should be coupled with robust
I think we have to distinguish two things here:

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
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.
> 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? I don't think so. And I think both cases
are signalled to the application for TCP in the same way.
> 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.
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.

Best regards
Michael

---

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Thu, 16 Jul 2015 12:26:08 +0200

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.
[Karen ] Yes, I agree.

>   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
>> [Karen ] Yes, but the user is not provided with the information that
>> the association was closed due to the receipt ICMPs.
ICMP
>Destination unreachable?

[Karen ] For TCP the socket api provides the information.
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.

BR, Karen
>>>> Hopefully we will see these things be clarified in future SCTP
>>>> drafts or ideally in the eventual RFC4960 revision.
>>>>
>>>> [Karen ] The state is not dead if "appropriate" dormant state
>>>> handling is implemented.
>>>>
>>>>> shut down a connection (heartbeat failure, retransmission failre)
>>>> Right now we have the possibility to use proprietary error codes
>>>> here, but we would like to go beyond that of course.
>>>>
>>>> And I agree with everybody else that this is a good exercise and
>>>> that it is doomed to (correct and) improve things substantially.
>>>>
>>>>> 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
>>>>>

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 16 Jul 2015 12:45:27 +0200

> On 16 Jul 2015, at 12:26, Karen Elisabeth Egede Nielsen <[email-masked]> wrote:
> 
> HI Michael,
>>> 
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?
> need to relate to this fact if the MAYs are followed.
OK.

Best regards
Michael

---

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Thu, 16 Jul 2015 13:13:10 +0200

HI Michael,

>From: Michael Tuexen [mailto:[email-masked]]
>Sent: Thursday, July 16, 2015 12:45 PM
>To: Karen Elisabeth Egede Nielsen
>Cc: Joe Touch; Pal Martinsen (palmarti); [email-masked]
>>> 1. When you receive an ICMP message you might increment the path
>>> error  counter or change the path state. When changing the path state
>> 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.
>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.

>> 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.
>>> that
>>> unreachable, have no reachable destinations anymore (dormant state)
>>> and have decided that this means failing the association. But again,
>>> this is
>> related
>> [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
[Karen ] Thanks for understanding.

BR, Karen
>>>>>> 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.
>>>>>> 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):
>>>>>>
>>>>>> else exists in our heads and in our overall modeling, now with
>>>>>> TAPS, may be defined as a concrete one.
>>>>>> [Karen ] We have studied this. But is only bringing this to the
>>>>>> IETF
>>>> now.

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 16 Jul 2015 22:29:10 +0200

> On 16 Jul 2015, at 13:13, Karen Elisabeth Egede Nielsen <[email-masked]> wrote:
> 
> HI Michael,
> 
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

---

From: Joe Touch <[email-masked]>
Date: Thu, 16 Jul 2015 14:32:54 -0700

...
> need (on why that is, see below).

IMO, the spec is what is deficient, in not requiring that this
information be available to the application. It is always the
application's prerogative to ignore such signals.

> transmit data also when the destinations are considered unreachable.

But the spec doesn't require that behavior. IMO, if the unreachable ends
up causing the connection to close, the application should be able to
figure out why.

...
>       this field.  This corresponds to the protocol error codes defined

Right - the issue is that COMMUNICATION LOST as described in RFC4960,
Sec 10.2, item "E", needs to include ICMP errors as a cause that
generates this error message. The current description covers only lost
heartbeats or aborts -- and while the ICMP could end up resulting in a
lost heartbeat, that's a different type of error to report as context.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 16 Jul 2015 14:34:16 -0700

> but an implementation issue.

IMO, it's a hole in the specification. It should be required by the
specification.

Yes, an implementation can exceed the specification, but that's
irrelevant to the discussion here, IMO.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 16 Jul 2015 14:35:44 -0700

> need to relate to this fact if the MAYs are followed.

Although that may be true for an implementation, the specification needs
to cover both sides of a MAY (i.e., what happens if the MAY is followed
and what happens when it is not).

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 16 Jul 2015 14:39:41 -0700

> (a) SCTP ignore ICMP destination unreachable, port unreachable

When it MUST ignore those signals, that's fine.

>     destination unreachable, protocol unreachable similar to an SCTP ABORT.

And this is the problem - when it acts on these signals, it never sends
any information to the user.

Further, ICMPs not otherwise defined are not required to be passed to
the application, as is required for TCP. That's a HUGE problem for ICMP
extensibility.

> will be notified if requested.

That's not strictly required by the spec.

Joe

---

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Fri, 17 Jul 2015 09:08:20 +0200

Hi Michael,
>It doesn't support ENETUNREACH. I don't think we do this in SCTP...
[Karen ] Yes. We do this for TCP (it is from rfc1122 I think),
but not for SCTP and it is not prescribed in RFC6458 or RFC4960 for SCTP.
This was the point of the notification discussion.

Ideally I would like to see:

* Path Failure and Assoc Change Event error fields are extended with new
error value to be given when
change is direct results of a received ICMP - and the ICMP should then
also be passed up.

NICE (or NOT NICE ?):

* Generally then receipt of ICMPs results in notifications (if
notifications are subscribed for of course).

I am not so sure about the second  as the notifications fills and take
resources - and this is soft ICMPs.
We have first and foremost focused on the first.

BR, Karen

>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.
>>
>>>>>> [Karen ] Yes, but even if the information is provided, then
>>>>>> closing the association does not constitute a soft reaction.
>>>>> again, this is
>>>> assocs enter dormant state fast and that dormant state
>>>> implementation need to relate to this fact if the MAYs are followed.
>>> OK.
>>>>>>>> [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
>>>>>>>> (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.
>>>>>>>>> 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.
>>>>>>>> code for the sac_error of the SCTP_ASSOC_CHANGE (the
>>>>>>>> notification of
>>>>>>> comm_LOST):
>>>>>>>>
>>>>>>>> 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.
>>>>>>>>> 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
>>>>>>>>>