Subject: [Taps] Hiding information from applications

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Mon, 30 Jun 2014 17:16:31 +0000

Continuing a thread on the actual work instead of on the charter, so new
subject.

On 6/27/14, 8:04 AM, "Michael Welzl" <[email-masked]> wrote:

>On 27. juni 2014, at 15:42, Spencer Dawkins
><[email-masked]> wrote:
>
>> On one point (that Michael said he was confused about below, so maybe
>>worth explaining better), Benoit and I spent about 20 minutes talking
>>before he balloted his block, and one thing we talked about was the
>>difference between an application knowing what's available on a platform
>>and knowing what's available on the path between two endpoints (so, if I
>>can send UDP to any port to Benoit, but a firewall between me and
>>Michael drops all UDP except for port 53, both of those facts are
>>relevant).
>> 
>> This is what we meant when Benoit said "which transport building blocks
>>work for me" below.
>
>Well, indeed, this is a design trade-off here that the group must figure
>out. Two example cases here:
>
>1) My own preference: TAPS hides pretty much everything that's
>path-related from the application, and we say "if you do care about such
>details, don't use TAPS, use the protocol you wish."
>
>2) Maybe someone else's, maybe Benoit's, preference: TAPS does not hide
>path-related information from the application.

This is likely to be an area of lively discussion early in the process.  I
almost completely disagree with hiding anything from the application:

- The application needs to know what semantics it got in order to do
*anything*

- The application is likely going to be the thing implementing the
protocol anyway, since I'm never going to get enough OSes to give me a new
kernel interface (evidence: SCTP)

- The semantics that the application requires in order to function are
mostly known at protocol design time

- Having to run a responder (e.g. server) that implements all possible
combinations is prohibitively expensive in several dimensions.  In
practice, it's going to be just a few that are (again) known at protocol
design time

- The application may want to be able to enter into a discussion with one
or more of the devices on path in order to negotiate better service

-- 
Joe Hildebrand

---

From: Michael Welzl <[email-masked]>
Date: Tue, 1 Jul 2014 00:00:40 +0200

> Continuing a thread on the actual work instead of on the charter, so new

and a very interesting discussion indeed! The crux of the matter  :-)

> - The application needs to know what semantics it got in order to do

... which is why I should never have used the word "hiding". Very sorry for that. Provide information, yes, but relieve application programmers from having to worry about these things and give some control to whatever they use. Not every application programmer wants to care about each and every detail of what goes on along a path, all the time - I'm getting the impression that the view of "application programmers" or "apps" people is biased in the IETF, towards... well, the kinds of app programmers who attend the IETF  :-)

> kernel interface (evidence: SCTP)

What's your "application"? You could have a middleware providing TAPS in user space.

> mostly known at protocol design time

I agree, but we're discussing whether the application needs to be concerned with *path-specific* information.

> practice, it's going to be just a few that are (again) known at protocol

Okaaay... so...?

> or more of the devices on path in order to negotiate better service

May want to => then it shall!  :-)

The question is really, what kinds of users are we building this for, and where do we draw the line re: flexibility vs. application control?

Cheers,
Michael

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Tue, 1 Jul 2014 00:00:08 +0000

On 6/30/14, 4:00 PM, "Michael Welzl" <[email-masked]> wrote:

>... which is why I should never have used the word "hiding". Very sorry
>for that. Provide information, yes, but relieve application programmers
>from having to worry about these things and give some control to whatever
>they use. Not every application programmer wants to care about each and
>every detail of what goes on along a path, all the time - I'm getting the
>impression that the view of "application programmers" or "apps" people is
>biased in the IETF, towards... well, the kinds of app programmers who
>attend the IETF  :-)

Perhaps, yes.  In my mind, the target audience of some of these bits are
library developers.  These folks can expose lots of events to higher-level
programmers, most of which might be ignored to start.  As an application
gets more interested in nuanced user experience, the library-using
developer can pay attention to more detail.

>What's your "application"?

In general, the applications I tend to think about have these properties:

- You download it from somewhere (e.g. Internet, app store, or corporate
repository)
- You install it yourself in a directory of your (or your admin's, or your
OS's) choosing
- It runs with your user privileges, nothing more
  - No raw sockets
  - No low-numbered ports
  - No access to DHCP information
- It is running on one or more of many operating systems
- It is written in one or more of many programming languages
- It speaks only through the socket API to the kernel, or a wrapper around
that API
- It has access to multiple active network interfaces, with some limited
ability to enumerate those devices and even less ability to query the
properties of those interfaces
- Its IP addresses change at least multiple times per day, sometimes
multiple times per minute
- It is behind a corporate firewall/NAT with an aggressive admin or it's
behind a crappy consumer firewall/NAT
- It has a crappy DNS library until the developer finds
http://getdnsapi.net/
- It might have one or more IPC mechanisms, but it might not!
- It might have filesystem access
- It might not stay connected when it goes into the background
- It might have threads
- Latency matters
- Security matters

- Power usage matters
- The app developer cares more about user experience than runtime cost
- The app developer has some server-side team they have to talk to, who
thinks the app developer is a (perhaps) necessary evil
- The server developers care more about cost per user than user experience
- The app developers and server developers are united in their dislike of
the corporate firewall admins, and will collude to work around them in
order to get paid.

There are likely other properties I didn't mention that are interesting.
Some of these are likely not interesting to everyone, or might not impact
the solution space.  However, I figured I'd make a start.

>You could have a middleware providing TAPS in user space.

Maybe.  As long as I didn't need to be root to install it or run it and
I'm running on an OS with an effective IPC mechanism that didn't open up
security holes.

>I agree, but we're discussing whether the application needs to be
>concerned with *path-specific* information.

I think this is the crux of the difference in approaches we're discussing.
 If the semantic changes with the path, I think it's hard to write an
application that continues to work.

>> practice, it's going to be just a few that are (again) known at protocol

So having a heavyweight mechanism to try 2000 options when only 2 will
work doesn't seem like something I would implement.  But it's possible
there's a way forward I haven't seen yet, and I look forward to hearing
more.

>May want to => then it shall!  :-)

If it has a mechanism to do so that is easy to use, standardized, and
accessible from user space.

>The question is really, what kinds of users are we building this for, and
>where do we draw the line re: flexibility vs. application control?

Yes, I think that's exactly the question we need to explore, and I'm
looking forward to learning a lot in the process.

-- 
Joe Hildebrand