On 6/5/2015 12:25 AM, Pal Martinsen (palmarti) wrote:
>
>> On 04 Jun 2015, at 22:56, Joe Touch <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>
>>
>> On 6/4/2015 12:51 PM, Pal Martinsen (palmarti) wrote:
>>>
>>>> On 04 Jun 2015, at 21:17, Joe Touch <[email protected]
>>>> <mailto:[email protected]>> 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".
>>>
>>> Heh.. I still do not get that..
>>>
>>>> From the Abstract:
>>> This document describes services provided by existing IETF protocols
>>> and congestion control mechanisms.
>>
>> *existing*
>>
>> That means we need to document WHAT IS before deciding to pursue WHAT
>> SHOULD BE.
>>
> ICMP is an *existing* protocol. Not a transport protocol, but a
> service(?) that affects how the other protocols behaves.
And it is part of the service provided by a transport - i.e., when an
ICMP message is absorbed and acted on by TCP, it's a service *to* TCP,
but when TCP relays ICMP messages to the application they become part of
the TCP API.
> All I am observing is that this is something app developers rarely cares
> about, and having sections in the TAPS transports draft describing it
> might help. Why are there sections describing TCP, they could just read
> RFC 793?
More like RFC1122, which already does for TCP and UDP basically what
this doc is attempting to do.
>>> It is designed to help
>>> application and network stack programmers and to inform the work of
>>> the IETF TAPS Working Group.
>>>
>>>
>>> Having a description of how ICMP works. Both in theory (abstract
>>> APIs) and in practice would help app developers.
>>
>> In theory, it behaves like RFC 792 and RFC 1122 specify.
>>
>> In practice, we can measure whether those capabilities are supported or
>> not (but that's not particularly the scope of TAPS).
>>
>> However, that does not necessarily require documenting the Java
>> interface to TCP on Linux CentOS v7. That what man pages are for.
>>
>
> No, but pointing out that there are differences out there and app
> developers should take care and investigate is a useful hint.
One line:
Implementations vary.
What else is there to say? And do we really need to say that?
>>>>>>> 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.
>>>>
>>>> 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.).
>>>>
>>>
>>> That seems like a fun task.. (So who is on the list: Apple,
>>> Microsoft, Google(android), Linux, BSD…)
>>
>> POSIX is maintained by the IEEE, and defines the common API across
>> various OS implementations - and yes, some of those orgs participate.
>>
>> That’s far outside the scope of the IETF, though.
>
>
> That I agree on. The discussion is probably better had over a beer. I do
> feel that it is important that IETF do take into account what is
> actually used in the wild.
That would require a survey, not merely anecdotal evidence.
>>>> ...
>>>>>> 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.
>>>>
>>> The section says:
>>> UDP MUST pass to the application layer all ICMP error
>>> messages that it receives from the IP layer. Conceptually
>>> at least, this may be accomplished with an upcall to the
>>> ERROR_REPORT routine (see
>>> Section 4.2.4.1).
>>>
>>> Looks like none the implementers do send any ICMP messages to the
>>> UDP layer.
>>
>> Here's an example of how an app can get errors in response to a call:
>> http://stackoverflow.com/questions/4888285/send-an-udp-packet-and-receive-an-icmp-response-from-router-in-c
>>
> Yes, I cited code example earlier.
>
> The above code does not fly so well unless you have administrative
> privileges.
That's an OS implementation issue. There's no such notion in our
protocols, except for the concept of system vs. user ports, and even
that is now somewhat deprecated as a distinction exactly because it
isn't uniformly enforced.
> I did a series of tests a while back. Code that works on OS-X, Linux and
> IOS can be found here:
> https://github.com/palerikm/ICMPTest
>
> Have code for windows as well, but that adds another layer of complexity
> and weirdness.
But that is a complaint against the implementation and/or user libraries.
>> The app can get async errors (i.e., not in response to a given sendmsg
>> or recvmsg call) by using a connect() to the socket - i.e., creating a
>> handle by which the OS can signal the app.
>>
>> See the book excerpt here:
>> https://books.google.com/books?id=ptSC4LpwGA0C&pg=PA249&lpg=PA249&dq=socket+errors+icmp&source=bl&ots=Ks3APlbjQs&sig=aBvReFfOYShEGtJtvEheG-8HpnI&hl=en&sa=X&ei=lLpwVdLHJZSZoQSxtYKwCw&ved=0CDMQ6AEwAg#v=onepage&q=socket%20errors%20icmp&f=false
>> <https://books.google.com/books?id=ptSC4LpwGA0C&pg=PA249&lpg=PA249&dq=socket+errors+icmp&source=bl&ots=Ks3APlbjQs&sig=aBvReFfOYShEGtJtvEheG-8HpnI&hl=en&sa=X&ei=lLpwVdLHJZSZoQSxtYKwCw&ved=0CDMQ6AEwAg#v=onepage&q=socket
>> errors icmp&f=false>
>>
>> AFAICT, this is widely supported.
>>
> We apparently live in two different realities. Figuring out how this
> work and implementing cross platform application code that does this is
> not trivial.
Again, that's an issue for organizations like the IEEE and POSIX.
> The above book does not describe how recent linux kernels handles ICMP.
There are Linux books and manual pages for this.
None of these are relevant to the IETF.
Joe
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
