Subject: [Taps] About old APIs from RFCs, and TAPS' real goal

From: Michael Welzl <[email-masked]>
Date: Wed, 27 Apr 2016 10:16:00 +0200

Hi all,

This is mainly about criticism from Toerless. I thought of sending him a private email (after I wanted to have a chat with him in Buenos Aires but ran out of time), but thinking some more, I decided that this is probably a matter of general interest: it's about the bigger picture of TAPS.

Toerless has repeatedly criticized the use of RFCs as a basis for developing the API in TAPS, when we have newer, better APIs available.

***side note***

Before continuing, let me pause and diverge a bit: much of Toerless' criticism was related to the UDP API, and, as far as I understand, multicast in particular (which isn't the focus of TAPS). Some of his concrete points may be absolutely right and, not knowing enough, I definitely don't take issue with them. Speaking for my own documents (drafts I'm co-authoring), I also do not want to be *religious* about using only the RFCs as a basis when it simply doesn't make sense - however I would like to use them as much as possible and consider diverging from my rules an exception, meaning that text should be marked or even put in an appendix. The reason for being so attached to the RFCs is that OSes have different concrete APIs, for good reason, and I think we want to maintain the freedom developers have in implementing their APIs as they wish.

***main point of this email***

Thinking about Toerless' general point of using more modern APIs made me think of the bigger picture again. For example, one cool recent feature in TCP APIs is the SO_SNDLOWAT socket option, which allows better control of the sender buffer. Not including it in an API document "sucks" and it IS nice to include it in a description of an API.

It is, however, also pretty irrelevant to the point of TAPS. Anyone is free to implement the SO_SNDLOWAT socket option today, we don't need TAPS for that. Neither do we need to change TCP for that. It's not even necessary to describe it for TCP to be able to use it (won't hurt but also won't gain us much).

I started the TAPS effort to ENABLE AUTOMATION.

This actually means *hiding* as much as possible. Today's stacks are highly optimized and a lot of automation happens - but some things are IMPOSSIBLE to automatize unless they are exposed in an API and an application uses them. SCTP contains some obvious examples: unordered delivery of messages and partial reliability. Try doing this to an application that expects a reliable byte stream. So, no system even tries to automatically use SCTP underneath the socket layer because many of its benefits could never be utilized.

This is why we need to do something. This is why TAPS exists - to specify that an API really should contain these transport service features (as we call them), so that more (richer) automation becomes possible. That's the whole point here. These are the transport service features that, in draft-gjessing-taps-minset, we call "functional".

At the last meeting, we authors of draft-gjessing-taps-minset got the feedback that we shouldn't put so much effort into trying to minimize the number of exposed services. I agree with this feedback, but here nevertheless I explain WHY we tried to minimize the number of services and why the charter says "the subset of those Transport Services, as identified in item 1, that end systems supporting TAPS will provide" - because, to me (and in line with the charter, I claim), the REAL goal of TAPS is to identify all these functional transport service features and explain how a TAPS system providing them could be implemented. I agree it makes sense to document more but I want to stress that that's not the main point. In other words, I think if we'd end up with a list of ONLY the functional transport service features of all the protocols we consider, and then explain how they can be provided, then TAPS has reached its goal: it would enable benefiting from other-than-TCP-or-UDP protocols.

It's my impression that discussions in TAPS are perhaps too much fueled by thinking about what modern APIs can do (as opposed to the old RFCs). I think there's no harm in that and it can be useful, but the REAL value comes from something else and we shouldn't lose focus on what really matters here. In other words, I believe that Toerless' criticism may be about things that aren't really very relevant to the goal of TAPS (because implementing them is not related to increasing the ability to automatize usage of mechanisms provided by protocols other than TCP and UDP - just like SO_SNDLOWAT can be implemented today, using TCP, and doesn't change anything about the intended automation). Note that I say may, because perhaps I AM missing the point as I didn't understand enough about the UDP API things he talked about, I do apologize if this is all just me misunderstanding him!

Thoughts?
(I am a little worried that nothing that I wrote is new to people, everyone agrees with me, and this is just me not getting Toerless' points   :(   )

Cheers,
Michael

---

From: Joe Touch <[email-masked]>
Date: Wed, 27 Apr 2016 14:25:50 -0700

On 4/27/2016 1:16 AM, Michael Welzl wrote:
> Thinking about Toerless' general point of using more modern APIs made
> me think of the bigger picture again. For example, one cool recent
> feature in TCP APIs is the SO_SNDLOWAT socket option, which allows
> better control of the sender buffer. Not including it in an API
> document "sucks" and it IS nice to include it in a description of an
> API.

This is an interesting example. It affects how a user-level process
interacts with the protocol implementation inside the OS but has NOTHING
to do with TCP.

I'm not sure where I would put that. It clearly isn't part of the TCP
API. Nor, e.g., would be the "nice" level of the process that's feeding
data to TCP -- yet both could affect performance between two applications.

It seems like there's a gap here you could drive a truck through that
needs to be addressed. I'm not sure where, though - i.e., whether this
is part of TAPS or not.

Joe