Re: [Taps] TAPS Transports and ICMP

Joe Touch <> Fri, 05 June 2015 16:42 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 798271A1BB1 for <>; Fri, 5 Jun 2015 09:42:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id V7ICOqbUAwIY for <>; Fri, 5 Jun 2015 09:42:38 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D94BC1A1B44 for <>; Fri, 5 Jun 2015 09:42:38 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id t55Gg8MW013521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 5 Jun 2015 09:42:17 -0700 (PDT)
Message-ID: <>
Date: Fri, 05 Jun 2015 09:42:06 -0700
From: Joe Touch <>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: "Pal Martinsen (palmarti)" <>
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
Archived-At: <>
Cc: "" <>
Subject: Re: [Taps] TAPS Transports and ICMP
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussions on Transport Services <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 05 Jun 2015 16:42:41 -0000

On 6/5/2015 12:25 AM, Pal Martinsen (palmarti) wrote:
>> On 04 Jun 2015, at 22:56, Joe Touch <
>> <>> wrote:
>> On 6/4/2015 12:51 PM, Pal Martinsen (palmarti) wrote:
>>>> On 04 Jun 2015, at 21:17, Joe Touch <
>>>> <>> 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
> 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 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
>>> 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
>>> 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:
> 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:
> 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:
>> <
>> 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.