> On 19 Jun 2015, at 12:07, Brian Trammell <[email protected]> wrote: > > hi Michael, > > A few replies inline. > >> On 18 Jun 2015, at 15:54, Michael Welzl <[email protected]> wrote: >> >> >>> On 17 Jun 2015, at 12:13, Brian Trammell <[email protected]> wrote: >>> >>> hi Michael, all, >>> >>> A couple of random points inline at various levels of quotation... >>> >>>> On 17 Jun 2015, at 10:44, Michael Welzl <[email protected]> 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.
I see. Well I don't have a problem with that, I was just suggesting that this is probably not the path of easy agreement. > <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. That makes sense to me. Cheers, Michael _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
