Re: [Taps] TAPS Transports and ICMP
Michael Tuexen <Michael.Tuexen@lurchi.franken.de> Thu, 04 June 2015 19:20 UTC
Return-Path: <Michael.Tuexen@lurchi.franken.de>
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 AD9BB1A894C for <taps@ietfa.amsl.com>; Thu, 4 Jun 2015 12:20:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.561
X-Spam-Level:
X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 Zr7DMo071Lv9 for <taps@ietfa.amsl.com>; Thu, 4 Jun 2015 12:20:04 -0700 (PDT)
Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 692571A894F for <taps@ietf.org>; Thu, 4 Jun 2015 12:20:04 -0700 (PDT)
Received: from [192.168.1.200] (p508F138D.dip0.t-ipconnect.de [80.143.19.141]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 39DD81C104358; Thu, 4 Jun 2015 21:20:01 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <5570988A.6040208@isi.edu>
Date: Thu, 04 Jun 2015 21:19:59 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <97FD8853-7345-40E9-A523-8AF53FB2303B@lurchi.franken.de>
References: <00597CB8-D128-408A-8F35-BA98CDF45A62@cisco.com> <55707211.8010609@isi.edu> <26B9DE0B-4D38-430D-A9A1-921CD0067C70@cisco.com> <5570988A.6040208@isi.edu>
To: Joe Touch <touch@isi.edu>
X-Mailer: Apple Mail (2.2098)
Archived-At: <http://mailarchive.ietf.org/arch/msg/taps/1_nBcOnb3UsFh4iairtaaxRGSLA>
Cc: "Pal Martinsen (palmarti)" <palmarti@cisco.com>, "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: Thu, 04 Jun 2015 19:20:06 -0000
> On 04 Jun 2015, at 20:27, Joe Touch <touch@isi.edu> wrote: > > > > On 6/4/2015 11:15 AM, Pal Martinsen (palmarti) wrote: >> >>> On 04 Jun 2015, at 17:43, Joe Touch <touch@isi.edu >>> <mailto:touch@isi.edu>> wrote: >>> >>> >>> >>> 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. >> >> 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. > >>> 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. >>> >> 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: >> 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. > > 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. > >>> 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. > >> 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. It is. See https://tools.ietf.org/html/rfc4960#appendix-C Best regards Michael > > Joe > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps
- [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