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

[Michael Welzl <[e-mail]>]

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