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