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

["Philipp S. Tiesel" <[e-mail]>]

Hi Michael,

> On 17. Jun 2017, at 12:02, Michael Welzl <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/taps
>> 
>> _______________________________________________
>> Taps mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/taps
> 
> _______________________________________________
> Taps mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/taps

AVE!
  Philipp S. Tiesel / phils…
-- 
   {phils}--->---([e-mail])--->---(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: [phone])---<---(jabber: [e-mail])----'