hi Michael, A few replies inline.
> On 18 Jun 2015, at 15:54, Michael Welzl <mich...@ifi.uio.no> wrote: > > >> On 17 Jun 2015, at 12:13, Brian Trammell <i...@trammell.ch> wrote: >> >> hi Michael, all, >> >> A couple of random points inline at various levels of quotation... >> >>> On 17 Jun 2015, at 10:44, Michael Welzl <mich...@ifi.uio.no> wrote: >>> >>>>> >>>>> I agree that the list below is closer to what I think a "component" >>>>> should be ... but looking at it, is it not even clearer now that >>>>> components are not what TAPS is after? To me this list now contains lots >>>>> and lots of details that are irrelevant to the service provided to the >>>>> application. >> >> That's part of the point we're trying to address here. The realization we >> had here is that components *don't* necessarily map to feature, and it's not >> clear that we can simply ignore those components that don't map, since they >> may have impact on the interfaces/features it is possible to (reasonably) >> implement atop those protocols. >> >>>>> Not harmful to list but pretty useless?! >> >> Let's start with TCP as probably the most difficult example (indeed, that's >> why we worked out this "new" arrangement of components for TCP first). A >> completely clean and unambiguous decomposition of TCP into its features -- >> what, I agree, we're after in the end -- is not *really* possible, because >> the protocols as defined and implemented weren't really composed of discrete >> features. The evolution of loss-based congestion control, for instance, was >> predicated on the particular loss signals that were available at the time it >> was first defined. The error detection mechanism likewise relies on the fact >> that reliability is provided by retransmission. One could say that given the >> parallel evolution of computing power that all these choices made by TCP >> were the only obvious ones at the time. But it's precisely the co-evolution >> of reliability and congestion control that makes gluing FEC to TCP so >> fraught with peril. That's an important point to capture IMO. >> >> I expect that the same exercise for SCTP will show a simpler mapping between >> components and features, since it *was* designed as a composition of >> features. > > I expect that too, but I still don't understand the point of the component > list above. I mean, yes, you may be able to map and say "we need components X > Y Z to provide features A and B" but how does this help TAPS? So as I see it, "features" are the TAPS view of the world of the future -- the set of things that transport protocols can do, and that a better interface can give you access to. "Components" are the view of the world of the present -- what the current definitions *and deployed implementations* of transport protocols can do, and what each of those features imply. There are a few ways you can implement the TAPS API. The one we chose to pursue in the WG (or at least I thought we had) is that the TAPS API takes (1) information from the application about its requirements in terms of features and parameters on those features (if available), (2) information from the path about which transport protocols and options are usable on the path, and the selects a transport protocol, and acts as glue between the API and the underlying protocol. In this approach, it is IMO important to catalog the protocol components (and the interactions among them) since the mappings between components and features might not be clean. This might not be the document to do that in. But we wanted to do the exercise to see what the outcome looked like. <snip> >>>> However, you could go for a even more generic approach and only look at >>>> the implementation and as a first step figure where are any knobs that in >>>> principle could be configurable and then afterwards discuss all of these >>>> very specific knobs. I though about this approach and think it would be an >>>> interest exercise and potentially the right way to go. But I also think >>>> that the overhead would be super large and I don’t think it would give us >>>> much more than we have right now. So we the current approach we might need >>>> to expect some arbitrariness… >>> >>> I lean towards this other one, of beginning with the knobs, >> >> ... understanding that interface definitions aren't just about which knobs >> (and indicators) the API provides, but also the interaction patterns it >> enables, and that these interaction patterns can also be made inefficient or >> even impractical by the details of the protocol in question. (It's always >> *possible* to implement object transfer over streams, or time domain >> transfer over objects, or to translate asynchonous events into a synchronous >> API. That the Web and video thereon "work" is proof of that. You can run the >> whole Internet over DNS, if you want to. It would not work as well as the >> one we have today. :) ) > > Yes, I agree, and I hope that this won't really bite us... or what's your > plan for addressing this problem? In this document, I don't think we need to do anything. If we take an API-centric view, we simply need to note the interaction pattern supported by each API. In the services and interfaces documents, I think we need to explicitly address which interaction patterns we want to support. >>> but not with the implementation but rather the "abstract API" as Joe called >>> it: the interface to the app as defined in the RFCs (for where it really >>> *is* defined). >>> >>> I think that this discussion with Joe maybe suffered from focusing on TCP. >>> SCTP is perhaps a better starting point because it supports almost >>> everything. >> >> We can certainly do SCTP next, which should make the exercise look less >> arbitrary. (FWIW I don't think we can *eliminate* arbitrary decisions in >> classification and where to cut the line between components, or to determine >> which components are worth talking about. But minimizing them is a good >> goal. :) ) >> >>> So I'm thinking that a different (and, to me, perhaps more appropriate and >>> more systematic) method to get a list of features could be to start with >>> the read / write options in RFC 6458, extend it with all such options from >>> the other protocols, and then, protocol by protocol, ask: "what does this >>> protocol provide that the list now doesn't contain?". Not sure the overhead >>> of this approach would be super large? But I agree, you may end up with >>> the same list the way you do it now. >> >> Again, that captures knobs and indicators, less so interaction patterns. (I >> will say I'm not 100% convinced the interaction patterns are important to >> capture for the individual protocols, but paying attention to them will be >> *crucial* to making sure that TAPS-the-system sees uptake among application >> and platform developers) > > I agree about that, but components won't capture these interaction patterns > either, or (why/how) would they? No, they won't -- I was responding to two separate points here, sorry... Cheers, Brian
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
