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

[Philipp S. Tiesel]

Hi Michael,

> On 17. Jun 2017, at 12:02, Michael Welzl  wrote:
> 
> 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.

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

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

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.

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

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.


> Cheers,
> Michael
> 
> 
> 
>> On Jun 16, 2017, at 8:23 PM, Tommy Pauly  wrote:
>> 
>> Hi Philipp,
>> 
>> Thanks for 

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

[Joe Touch]

On 6/16/2017 11:23 AM, Tommy Pauly wrote:
> - 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.

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

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

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

[Philipp S. Tiesel]

Hi Tommy,

thanks for your appreciation and comments.
 
> 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.

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

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

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!
  Philipp S. Tiesel / phils…

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

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

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

[Michael Welzl]

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  wrote:
> 
> 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  wrote:
>> 
>> 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 

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

[Tommy Pauly]

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  wrote:
> 
> 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…
> 
> ___
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps