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

[Michael Welzl <[e-mail]>]

Hi,


> On Jun 24, 2017, at 1:16 PM, Philipp S. Tiesel <[e-mail]> wrote:
> 
> 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.

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


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


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

Cool!

Cheers,
Michael