Subject: [Taps] Socket Intents Draft – draft-tiesel-taps-socketintents-00

From: "Philipp S. Tiesel" <[email-masked]>
Date: Fri, 16 Jun 2017 10:54:26 +0200

Hi,

I just uploaded draft-tiesel-taps-socketintents-00 to the data tracker yesterday.
https://datatracker.ietf.org/doc/draft-tiesel-taps-socketintents/

This draft should fits into point three of the TAPS charter.
 
Socket Intents allow applications to share their knowledge about upcoming
communication and express their performance preferences in an API independent way.
Therefore, thy can be used by an OS/API to gain enough knowledge to perform access
as well as transport protocol selection and tuning.

A draft explaining an experimental implementation based on BSD sockets will follow.

I am looking forward to the discussion, here and in Prague.

AVE!
  Philipp S. Tiesel / phils…

---

From: Tommy Pauly <[email-masked]>
Date: Fri, 16 Jun 2017 11:23:20 -0700

Hi Philipp,

Thanks for sharing this document! Providing an API for generic network intents is something of a Holy Grail—valuable but elusive to nail down. This document should be a good place to start a conversation, and I look forward to discussing it in Prague.

A few initial comments:

- I’d love to see the terminology be less sockets-specific, especially considering the work for Post-Sockets APIs. A set of intents should be able to be applied to individual messages being sent or on a higher-level protocol, ideally, not just on the level of a transport connection as represented by a socket.

- Certain properties, like burstiness, are focused on what the application will be sending, and what its sending pattern will look like. This works fine for some use cases, but in the case of downloads, the application may not have enough/any insight into what patterns the server will have. What do you think the best way to account for this is?

- While explicit intents are a great way to avoid ossification, I would also argue that we should minimize the surface of the intents in order to reduce the complexity for application writers. Do you think that some of these intent properties can also be inferred automatically based on the traffic patterns observed by the system? I’m thinking here of traffic category, in which we’re asking the app to say if they’re using queries or streams or bulk downloads, etc.

Thanks,
Tommy

> On Jun 16, 2017, at 1:54 AM, Philipp S. Tiesel <[email-masked]> wrote:
> 
> Hi,
> 
> _______________________________________________
> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps

---

From: Michael Welzl <[email-masked]>
Date: Sat, 17 Jun 2017 12:02:14 +0200

Hi,

Thanks indeed for sharing this - I think this is very interesting input to the group.
I agree with the things Tommy says below, but I have some additional thoughts that I wanted to share.

Our charter is about existing protocols and what they can do. For TCP, MPTCP, UDP, UDP-Lite, SCTP and LEBAT, draft-gjessing-taps-minset breaks this list down into transport features that really must be exposed in order to become usable, some that really shouldn’t be exposed (as they would forever tie your application to one specific protocol only), and some that could (perhaps) be automatized.

So, with that in mind, if I try to imagine how to implement a system implementing draft-tiesel-taps-socketintents on top of TCP, MPTCP, UDP, …etc, I see two degrees of freedom here:

1) deciding which protocol to use, and making good use of the features that we call “automatable” in draft-gjessing-taps-minset. As a concrete example, we say that the choice of the network interface is based on network- or OS-wide, but not application-specific knowledge, and so it should be automatable. However, making a choice does need *some* knowledge about app behavior, and this is exactly a hole that some of the things in draft-tiesel-taps-socketintents appear to fill.

2) I guess that some of the services of protocols can be “translated” into a slightly different representation. Here I’m thinking of your “Application Resilience”, for example: how does this relate to "Change timeout for aborting connection (using retransmit limit or time value)” (from (MP)TCP and SCTP) and "Suggest timeout to the peer” (from (MP)TCP, via UTO)?   Isn’t a very disruption-resilient application going to want a large timeout value?  But then maybe such resilience is best configured in seconds…

and “timeliness” in your section 5.6 pretty obviously maps to "Specify DSCP field” (from (MP)TCP, SCTP and UDP(-Lite)) - which we actually already combined with other things and translated into a higher-level representation that we call “capacity profile” in https://tools.ietf.org/html/draft-gjessing-taps-minset-04#section-5.5

I understand that the idea of socket intents is to describe an application’s behaviour, not request QoS - but using the DSCP as in draft-ietf-tsvwg-rtcweb-qos isn’t about guarantees either. All in all, considering just the API, I don’t see much difference between an application using socket intents and choosing “background” or using the DSCP value and choosing “background”. Once a TAPS system has this information, the question becomes what it really does with it (truly set the DSCP value, or do something else?).

So these were just some thoughts. To summarize, I think it would be interesting to see how the things in draft-tiesel-taps-socketintents map to:
- the choice of protocols
- configuring transport features of existing protocols that we call “automatable”
- and simply using transport features that, according to draft-gjessing-taps-minset, already should be exposed anyway. 

Cheers,
Michael

> On Jun 16, 2017, at 8:23 PM, Tommy Pauly <[email-masked]> wrote:
> 
> Hi Philipp,
>

---

From: "Philipp S. Tiesel" <[email-masked]>
Date: Sat, 17 Jun 2017 13:37:56 +0200

Hi Tommy,

thanks for your appreciation and comments.
 
> - I’d love to see the terminology be less sockets-specific, especially considering the work for Post-Sockets APIs. A set of intents should be able to be applied to individual messages being sent or…

I totally agree that the Idea of Intents is not limited to sockets and the transport layer, but the Idea started from there.   

Background: The the original idea was very close to the sockets and targeted at deciding which network interface to use for upcoming connections. We extended this in the meantime to smaller communication units (HTTP Request/Response pairs) and it worked very well in simulations and our prototype using the "Object Size” Intent. I try to give more background on this in an additional draft. 

I take making the terminology be less sockets-specific as a ToDo-Item for the -01 version.

By introducing an applicability scope and choosing levels that do not directly map the protocol layering, but an abstract 
layering of functionality (Flow, Association, Stream, or Object level), I took the first step towards a more generic abstraction.
For me, Object level indeed would include individual messages in an application layer protocol like HTTP Requests.

Question: Is this sufficient or do we need to need more or different levels?
We might also consider postponing this question as we are now in the progress of writing a draft on explaining
this levels and how multipath-funtionality may be distributed over them. 

> - Certain properties, like burstiness, are focused on what the application will be sending, and what its sending pattern will look like. This works fine for some use cases, but in the case of downl…

Currently, In this cases I would either not set the Intent at all or explicitly to "mixed/don’t know”.
I consider setting Intents best effort - what the application doesn’t know it can't communicate.

Therefore, some of the Intents are not really overlap-free. Setting “Object Size” to something really large, the "Traffic Category” is pretty obvious even when not set. This also plays into you next question. 

> - While explicit intents are a great way to avoid ossification, I would also argue that we should minimize the surface of the intents in order to reduce the complexity for application writers. Do y…

I don’t see having Intents and inferring their values as exclusive, but as complementary. 
I anticipate inferring traffic pattern will work fine for many applications, but not for all. 

What I definitely want to avoid is application developers having to train machine learning algorithms in order to have their applications working. Therefore, I prefer exposing more Intents and making them optional over relying on being able to infer them.

AVE!

-- 
   {phils}--->---([email-masked])--->---(http://phils.in-panik.de)----,
      wenn w eine   aube ist dn      man au dran dre en                   |
           o     Schr        an muss     hc         h   (Kurt Schwitters) |
:wq!  <----(phone: +49-179-6737439)---<---(jabber: [email-masked])----'

---

From: Joe Touch <[email-masked]>
Date: Mon, 19 Jun 2017 06:16:31 -0700

> - I’d love to see the terminology be less sockets-specific, especially considering the work for Post-Sockets APIs. A set of intents should be able to be applied to individual messages being sent or…

I sincerely hope this and other TAPS documents are more specific about
what is meant by a "socket".

An Internet socket is an IP address paired with a transport protocol
port (RFC793), such that a socket pair defines a connection (TCP, SCTP,
DCCP) or association (UDP).

A Unix socket is a OS mechanism that allows user-space applications to
access transport-layer connections or associations.

The two are otherwise not related; there are many Unix socket parameters
focusing on the OS user-space to kernel-space interface, interprocess
communication management, etc, and have no relation to Internet socket
pairs. Unix sockets do not represent transport connections; they are
interfaces that include access to the transport API.

Joe

---

From: "Philipp S. Tiesel" <[email-masked]>
Date: Sat, 24 Jun 2017 13:16:02 +0200

Hi Michael,

> On 17. Jun 2017, at 12:02, Michael Welzl <[email-masked]> wrote:
> 
> Hi,
> 
> 2) I guess that some of the services of protocols can be “translated” into a slightly different representation.

The third (and primary use-case for Socket Intents so far) was using them for Access-Selection, which includes automatic selection of transport options like destination, path, and what packet / stream scheduling strategy to use for MPTCP and SCPT.
As far as I interpret draft-gjessing-taps-minset and the WG charter, this is not exactly the focus of the WG, but also not out of scope.
I think we should put this a little clearer in a -01 version of the draft-tiesel-taps-socketintents.

> Here I’m thinking of your “Application Resilience”, for example: how does this relate to "Change timeout for aborting connection (using retransmit limit or time value)” (from (MP)TCP and SCTP) and "Suggest timeout to the peer” (from (MP)TCP, via UTO)?   Isn’t a very disruption-resilient application going to want a large timeout value?  But then maybe such resilience is best configured in seconds…

One of the Ideas of Socket Intents is that intents are expressed in an abstract way. While a timeout in seconds is indeed a value that is protocol independent, it is very concrete and therefore fits much better in the abstract mindset api than into socket intents.

Application Resilience as stated in draft-tiesel-taps-socketintents-00 is useful for transport option selection and deriving a timeout default. This can be either adjusted by explicitly setting a timeout or an by an additional intent like “Connection Failure Detection Sensitivity”.

> I understand that the idea of socket intents is to describe an application’s behaviour, not request QoS - but using the DSCP as in draft-ietf-tsvwg-rtcweb-qos isn’t about guarantees either. All in…

Correct. capacity profile and the “timeliness” and “category” Intent differ mainly in their scope of effect: while the Intents are primarily thought as input to automatic transport option selection, the capacity profile is primarily a way to specify the DSCP field. Nevertheless, the value of the Intents can be used to derive the DSCP filed if desired.

> - and simply using transport features that, according to draft-gjessing-taps-minset, already should be exposed anyway. 

Reasonable questions - I don’t know whether I will find the time to elaborate on this in the draft till the cutoff date for Prague, but I agree that these relations should be clarified in a future version of the draft.

AVE!

---

From: Michael Welzl <[email-masked]>
Date: Sat, 24 Jun 2017 18:39:23 +0200

Hi,

> On Jun 24, 2017, at 1:16 PM, Philipp S. Tiesel <[email-masked]> wrote:
> 
> Hi Michael,
> 

I’d classify access selection as my item 1) above: it’s one of the things (e.g. of MPTCP) that we call “automatable”. Now just because it *might* be possible to automate access selection, this doesn’t mean that it wouldn’t be better to add more information from the application to make a better decision - the minset is indeed only a “minimum set”.

> Application Resilience as stated in draft-tiesel-taps-socketintents-00 is useful for transport option selection and deriving a timeout default. This can be either adjusted by explicitly setting a t…

I understand, and I’m in favor of raising the abstraction level a bit (for the sake of greater flexibility) - as long as there’s at least one clear implementation possibility, using existing protocols.

> Reasonable questions - I don’t know whether I will find the time to elaborate on this in the draft till the cutoff date for Prague, but I agree that these relations should be clarified in a future…

Cool!

Cheers,
Michael