Sorry for sending an extra email - I just had an extra thought and think this is important to add:
Below: > On 5. jun. 2015, at 11.05, Michael Welzl <mich...@ifi.uio.no> wrote: > > >> On 5. jun. 2015, at 10.12, Mirja Kühlewind <mirja.kuehlew...@tik.ee.ethz.ch> >> wrote: >> >> Okay, just to quickly clarify. In the charter only the word service is used. >> We defined later on the words component and feature which are currently not >> reflected in the charter. The part I've cited below, I think, it should say >> components. However, it does not really matter because we will in the >> current document first identify components and then discuss features. In any >> case this document will not define a new interface. > > I got that but I disagree about "it should say components" for the part in > the charter: from the definition, the component is an implementation, not > what is exposed to the application. I think the more important part is to > capture what's exposed to the application. For example: SCTP has a component > called "strong error detection (CRC32C)". TCP has a component called "error > detection (checksum)". This is probably not exposed to the application as > such by any of these protocols. I'll explain below why this makes it less > important in my opinion... > > >> I'd also say that this is not the flag ship document (as stated by Joe). The >> flagship document probably is the third item on the charter which then will >> probably also talk about the interface in more detail (charter says on the >> third doc: "This document will explain how to select and engage an >> appropriate protocol ..."). > > Well, this first document is no less important, everything hinges on it. > > So let's think of the future system we're envisioning here. Is it going to > provide "error detection" as a service? Is it going to provide "strong error > detection"? > > When making these decisions, I think we'd first need to go through the list > of things provided to applications by the protocols in what Joe calls the > abstract API. Probably we won't find it there: it's a static property of the > protocols AFAIK. So, next, we go through all the static properties to figure > out what we need to expose. Then, the question becomes: should a TAPS system > decide for or against SCTP based on the level of error protection? Is this a > basis for deciding for this or the other protocol? > > These are important decisions but I think they are secondary, whereas what > the protocols now explicitly offer is primary - because it would be very > strange not to offer what is being offered today. We can decide to not expose > "level of error protection" and give the TAPS more freedom in choosing the > protocol; given that the goal is to stop connection applications to specific > protocols, we CAN do that. as Brian pointed out in a previous email, a protocol comes with a series of what he called "positive properties" and "negative properties". Anyway, properties: your application may like some and hate some. It's always a suite of properties - then, we probably can't expose them individually - e.g. with today's protocols, you can't get MPTCP's usage of multiple paths with coupled congestion control but at the same time have SCTP's strong CRC. Sure, we can say the same about combinations of things that are currently being offered in the abstract APIs of the protocols, but still, things will get easier there: the list is shorter, it's clearer what we need to include and what not (basically everything must be included), and certain API elements will clearly dictate which protocol(s) to use. Therefore I do believe that the job gets much easier if we focus on the abstract APIs first. I'm not against listing the components, it's about what matters more (and it should be reflected in the document accordingly - maybe it could even be an idea to split the document in two, one purely about the "abstract API" and one about "components", and possibly merge them later?). Cheers, Michael _______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
