Hi Michael, > On 17. Jun 2017, at 12:02, Michael Welzl <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/taps >> >> _______________________________________________ >> Taps mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/taps > > _______________________________________________ > Taps mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/taps AVE! Philipp S. Tiesel / phils… -- {phils}--->---([email protected])--->---(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 protected])----' _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
