Re: [Taps] TAPS Transports and ICMP
"Pal Martinsen (palmarti)" <palmarti@cisco.com> Fri, 05 June 2015 07:25 UTC
Return-Path: <palmarti@cisco.com>
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C1C71B2CFA for <taps@ietfa.amsl.com>; Fri, 5 Jun 2015 00:25:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Up4nLKXAoWgf for <taps@ietfa.amsl.com>; Fri, 5 Jun 2015 00:25:16 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28F971B2CC9 for <taps@ietf.org>; Fri, 5 Jun 2015 00:25:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=53612; q=dns/txt; s=iport; t=1433489116; x=1434698716; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=EpSX9I2xmI1ld6cUgvzEKymfPvR2H6/W41+SoS9sj9U=; b=h5czXxW8vvakkbouxdQ11FowQip0QBlkguL+NJOs0ceCRKw5d2/4oZZr PuQhMLo1ROiWfzgVeKuur65aOgcxNY3vB1cnkGmhviX/vGPCi6MY9a8cx EBI09o1B3fVmv101Wra/gkxlqL6DmWN526KqC6pBSFqQLzHjK7CPvbbT6 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0C2AAC6TXFV/4wNJK1bDoI3S1ReBoMYrQiPKQVthXoCHIEUTAEBAQEBAYELhCMBAQQjVhACAQgtCwEGAwICAjAUEQIEDgUWA4gUDbdGpBgBAQEBAQEBAQEBAQEBAQEBAQEBAQEXi0OEaxcEBwqCXi+BFgWFS4sUgkCEP2GBMYRWgS8+hjmPLyRhgSgcgRQ+bwGBRYEBAQEB
X-IronPort-AV: E=Sophos;i="5.13,557,1427760000"; d="scan'208,217";a="425504410"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-7.cisco.com with ESMTP; 05 Jun 2015 07:25:15 +0000
Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t557PFdT027775 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Jun 2015 07:25:15 GMT
Received: from xmb-rcd-x06.cisco.com ([169.254.6.183]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Fri, 5 Jun 2015 02:25:14 -0500
From: "Pal Martinsen (palmarti)" <palmarti@cisco.com>
To: Joe Touch <touch@isi.edu>
Thread-Topic: [Taps] TAPS Transports and ICMP
Thread-Index: AQHQnrPt38kKNK6QP0icmFYJs5spRZ2c0L6AgAAqlgCAAANHAIAAC3cAgAAClACAAAmTAIAAEfcAgACvvgA=
Date: Fri, 05 Jun 2015 07:25:13 +0000
Message-ID: <9288CE6B-2BEE-4E11-AD79-9C7601AFB27B@cisco.com>
References: <00597CB8-D128-408A-8F35-BA98CDF45A62@cisco.com> <55707211.8010609@isi.edu> <26B9DE0B-4D38-430D-A9A1-921CD0067C70@cisco.com> <5570988A.6040208@isi.edu> <554F884C-642C-42B1-A976-EECD0C32928B@cisco.com> <5570A452.8090209@isi.edu> <43C5480A-904D-4A7E-A181-08EBA709BC2A@cisco.com> <5570BB6C.2070905@isi.edu>
In-Reply-To: <5570BB6C.2070905@isi.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.61.72.232]
Content-Type: multipart/alternative; boundary="_000_9288CE6B2BEE4E11AD799C7601AFB27Bciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/taps/vJ24uVrE6RlpIMWm_eSQURR2o_0>
Cc: "taps@ietf.org" <taps@ietf.org>
Subject: Re: [Taps] TAPS Transports and ICMP
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussions on Transport Services <taps.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/taps>, <mailto:taps-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/taps/>
List-Post: <mailto:taps@ietf.org>
List-Help: <mailto:taps-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/taps>, <mailto:taps-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Jun 2015 07:25:19 -0000
On 04 Jun 2015, at 22:56, Joe Touch <touch@isi.edu<mailto:touch@isi.edu>> wrote: On 6/4/2015 12:51 PM, Pal Martinsen (palmarti) wrote: On 04 Jun 2015, at 21:17, Joe Touch <touch@isi.edu<mailto: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". 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. 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 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. 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. ... 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. 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. 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. 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 ... 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. Do you have any real code to show that this actually work as described on any platform? See above. Joe
- [Taps] TAPS Transports and ICMP Pal Martinsen (palmarti)
- Re: [Taps] TAPS Transports and ICMP Joe Touch
- Re: [Taps] TAPS Transports and ICMP Pal Martinsen (palmarti)
- Re: [Taps] TAPS Transports and ICMP Joe Touch
- Re: [Taps] TAPS Transports and ICMP Pal Martinsen (palmarti)
- Re: [Taps] TAPS Transports and ICMP Joe Touch
- Re: [Taps] TAPS Transports and ICMP Michael Tuexen
- Re: [Taps] TAPS Transports and ICMP Pal Martinsen (palmarti)
- Re: [Taps] TAPS Transports and ICMP Joe Touch
- Re: [Taps] TAPS Transports and ICMP Michael Tuexen
- Re: [Taps] TAPS Transports and ICMP Pal Martinsen (palmarti)
- Re: [Taps] TAPS Transports and ICMP Joe Touch
- Re: [Taps] TAPS Transports and ICMP Karen Elisabeth Egede Nielsen
- Re: [Taps] TAPS Transports and ICMP Joe Touch
- Re: [Taps] TAPS Transports and ICMP Karen Elisabeth Egede Nielsen
- Re: [Taps] TAPS Transports and ICMP Michael Tuexen
- Re: [Taps] TAPS Transports and ICMP Michael Tuexen
- Re: [Taps] TAPS Transports and ICMP Karen Elisabeth Egede Nielsen
- Re: [Taps] TAPS Transports and ICMP Michael Tuexen
- Re: [Taps] TAPS Transports and ICMP Karen Elisabeth Egede Nielsen
- Re: [Taps] TAPS Transports and ICMP Michael Tuexen
- Re: [Taps] TAPS Transports and ICMP Karen Elisabeth Egede Nielsen
- Re: [Taps] TAPS Transports and ICMP Michael Tuexen
- Re: [Taps] TAPS Transports and ICMP Joe Touch
- Re: [Taps] TAPS Transports and ICMP Joe Touch
- Re: [Taps] TAPS Transports and ICMP Joe Touch
- Re: [Taps] TAPS Transports and ICMP Joe Touch
- Re: [Taps] TAPS Transports and ICMP Karen Elisabeth Egede Nielsen