Re: [Taps] TAPS Transports and ICMP

["Pal Martinsen (palmarti)" <[e-mail]>]

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

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

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.

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

So this boils down better education of the app developers?

> 
>>> 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.
> 
Can they at least cite RFC 1122 then?

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

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

.-.
Pål-Erik

> Joe