Hi,
> On Jun 24, 2017, at 1:16 PM, Philipp S. Tiesel <[email protected]> wrote: > > 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. 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 _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
