Re: [Taps] TAPS Transports and ICMP

> On 04 Jun 2015, at 21:17, Joe Touch <touch@isi.edu> wrote:
> 
> 
> 
> On 6/4/2015 12:08 PM, Pal Martinsen (palmarti) wrote:
> ...
>>> UDP passes all ICMP messages to the app. If the app doesn't listen for
>>> it, that’s the app's decision.
>>> 
>> Then there is a lot UDP application developers out there that does not care. 
>> 
>> Ill guess what I am asking if we should make life easier for them.
> 
> Again, FIRST this doc needs to explain the current abstract APIs for
> transport protocols.
> 
> THEN we can decide whether that set either needs to be augmented,
> diminished, or translated to be more useful for "applications".
> 
>>>> 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.
>>> 
>> On purpose. I hate it when a feature should work because it says so 
>> in a RFC, but the implementations of it is so vastly different that
>> it is not possible to get the thing to work so the app developer just
>> chose to ignore it.
> 
> The IETF standardizes protocols and abstract APIs.
In the case of SCTP, the IETF also specifies an extension to the socket
API covering SCTP. See
https://tools.ietf.org/html/rfc6458
and corresponding "Socket API Consideration" sections in SCTP specifications.
An abstract API is specified in
https://tools.ietf.org/html/rfc4960#section-10
However, this doesn't help for writing portable application. Therefore,
having RFC 6458 has helped to guide the SCTP implementations in FreeBSD,
Linux and Solaris to provide implementations for which you can write
programs for.

Best regards
Michael
> 
> If you are concerned with differences in the implementations of those
> abstract APIs, you need to address them in other organizations (e.g.,
> POSIX, etc.).
> 
> ...
>>> 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.
>> 
>> That is another problem. An app using port 5555 will receive all
>> ICMP messages also generated by other apps running on other ports.
> 
> That's an incorrect implementation. See RFC1122 Section 4.1.3.3.
> 
> ...
>> So this boils down better education of the app developers?
> 
> No, in that case you have a bug. The only thing the UDP app has to worry
> about are ICMPs from other apps using the same port.
> 
>>>>> 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.
>>> 
>> Can they at least cite RFC 1122 then?
> 
> I would hope so.
> 
> Joe
> 
> _______________________________________________
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps