Re: [Taps] TAPS Transports and ICMP

Joe Touch <> Thu, 04 June 2015 18:28 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 379171A8855 for <>; Thu, 4 Jun 2015 11:28:07 -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 stD8PDPdzwfP for <>; Thu, 4 Jun 2015 11:28:03 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 378081A8840 for <>; Thu, 4 Jun 2015 11:28:03 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id t54IRNOw003660 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 4 Jun 2015 11:27:23 -0700 (PDT)
Message-ID: <>
Date: Thu, 04 Jun 2015 11:27:22 -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-MailScanner-ID: t54IRNOw003660
X-ISI-4-69-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: Thu, 04 Jun 2015 18:28:07 -0000

On 6/4/2015 11:15 AM, Pal Martinsen (palmarti) wrote:
>> On 04 Jun 2015, at 17:43, Joe Touch <
>> <>> 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 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.