Subject: [Taps] TAPS Transports and ICMP

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Thu, 4 Jun 2015 10:48:01 +0000

Hi,

I was wondering…

Today app developers actively need to listen for ICMP messages and do smart things (tm) if they receive them. ICMP also offers a nice set of tools to do a few neat tricks. Application developers rarely bothers to care about that. 

Does it make sense for the TAPS transports draft to add ICMP? ICMP feedback can possibly influence how the other transport protocols in the draft behave.

 .-.
Pål-Erik

---

From: Joe Touch <[email-masked]>
Date: Thu, 04 Jun 2015 08:43:13 -0700

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.

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.

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.

Joe

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Thu, 4 Jun 2015 18:15:39 +0000

On 04 Jun 2015, at 17:43, Joe Touch <[email-masked]<mailto:[email-masked]>> wrote:

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.

No. Not unless the application specifically listens for it. 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.

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.

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.

Any pitfalls with ICMP when doing SCTP?

.-.
Pål-Erik

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 04 Jun 2015 11:27:22 -0700

On 6/4/2015 11:15 AM, Pal Martinsen (palmarti) wrote:
> 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.

> 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:

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.

> That is exactly that kind of information I would find useful in the

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.

Joe

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Thu, 4 Jun 2015 19:08:24 +0000

> On 04 Jun 2015, at 20:27, Joe Touch <[email-masked]> wrote:
> 
> 
> 
> 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.

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

If TAPS ends up like the ICMP abstract interfaces it would make life even harder for the app developers trying to get things working on various platforms.

> 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. Trivial to find the ones that belongs to you if you know how. 

So this boils down better education of the app developers?

> Well, yes - IMO, that’s because it's part of the abstract API.
> 
Can they at least cite RFC 1122 then?

> probably buried in the SCTP docs.

Thanks. Useful discussion for me. Not so sure if it was useful for rest of the TAPS list. Sorry about that.

.-.
Pål-Erik

---

From: Joe Touch <[email-masked]>
Date: Thu, 04 Jun 2015 12:17:38 -0700

On 6/4/2015 12:08 PM, Pal Martinsen (palmarti) wrote:
...
> 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".

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

> Can they at least cite RFC 1122 then?

I would hope so.

Joe

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 4 Jun 2015 21:19:59 +0200

> probably buried in the SCTP docs.
It is. See
https://tools.ietf.org/html/rfc4960#appendix-C

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

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Thu, 4 Jun 2015 19:51:55 +0000

> On 04 Jun 2015, at 21:17, Joe Touch <[email-masked]> wrote:
> 
> 
> 
> 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.  It is designed to help
application and network stack programmers and to inform the work of
the IETF TAPS Working Group.

Having a description og how ICMP works. Both in theory (abstract APIs) and in practice would help app developers.

> abstract APIs, you need to address them in other organizations (e.g.,

That seems like a fun task.. (So who is on the list: Apple, Microsoft, Google(android), Linux, BSD…)

> 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. So technically they are not violating this part of the spec. 

> about are ICMPs from other apps using the same port.

Do you have any real code to show that this actually work as described on any platform?

If nobody actually follows it I would consider it a dead spec. I thought in the good old days two various implementations was needed to get the RFC through?
I really hope we can get more running code in TAPS and not hide behind virtual interfaces. 

.-.
Pål-Erik

---

From: Joe Touch <[email-masked]>
Date: Thu, 04 Jun 2015 13:56:12 -0700

On 6/4/2015 12:51 PM, Pal Martinsen (palmarti) wrote:
> and congestion control mechanisms.

*existing*

That means we need to document WHAT IS before deciding to pursue WHAT
SHOULD BE.

> It is designed to help
> 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.

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

> 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

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

AFAICT, this is widely supported.

> Do you have any real code to show that this actually work as described on any platform?

See above.

Joe

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 4 Jun 2015 23:04:14 +0200

> 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

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Fri, 5 Jun 2015 07:25:13 +0000

On 04 Jun 2015, at 22:56, Joe Touch <[email-masked]<mailto:[email-masked]>> wrote:

On 04 Jun 2015, at 21:17, Joe Touch <[email-masked]<mailto:[email-masked]>> wrote:

From the Abstract:

*existing*

ICMP is an *existing* protocol. Not a transport protocol, but a service(?) that affects how the other protocols behaves.

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?

It is designed to help

No, but pointing out that there are differences out there and app developers should take care and investigate is a useful hint.

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.

That seems like a fun task.. (So who is on the list: Apple,
Microsoft, Google(android), Linux, BSD…)

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.

...

The section says:

Yes, I cited code example earlier.

The above code does not fly so well unless you have administrative privileges.

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.

We apparently live in two different realities. Figuring out how this work and implementing cross platform application code that does this is not trivial.

The above book does not describe how recent linux kernels handles ICMP.

.-.
Pål-Erik

...

See above.

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 05 Jun 2015 09:42:06 -0700

On 6/5/2015 12:25 AM, Pal Martinsen (palmarti) wrote:
> 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.

> 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?

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

> The above code does not fly so well unless you have administrative

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.

> Have code for windows as well, but that adds another layer of complexity

But that is a complaint against the implementation and/or user libraries.

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