> On 05 Jun 2015, at 16:03, Michael Welzl <mich...@ifi.uio.no> wrote: > > >> On 05 Jun 2015, at 15:52, Michael Tuexen <michael.tue...@lurchi.franken.de> >> wrote: >> >>> On 05 Jun 2015, at 15:39, Michael Welzl <mich...@ifi.uio.no> wrote: >>> >>> >>>> On 05 Jun 2015, at 12:35, Michael Tuexen >>>> <michael.tue...@lurchi.franken.de> wrote: >>>> >>>>> On 05 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. >>>> I consider "protecting against bit errors" a service. And I think the >>>> level is important. I agree, TCP and SCTP provide >>>> a protocol dependent level of protection, so there is no need to expose >>>> this in the API of the particular protocol, >>>> however, I do think someone wants a strong checksum or not, and that will >>>> influence the choice of protocols. >>>> So we do have services which are not configurable via the API. >>> >>> Just for clarification: this wasn't about whether the level of "protection >>> against bit errors" as such is important or not: I think the level of >>> protection is a less important item to cover in the first document because, >>> given current protocols (what this doc is about), you can't just switch it >>> on or off - it comes with a choice of a whole protocol. So it's just a part >>> of a protocol description - static protocol properties that come as a whole >>> whenever you pick the protocol. >> Such as "reliable" for TCP? Or "byte stream" for TCP? These properties come >> with choosing TCP... > > Exactly. > > I meant "important" as "to be discussed first" (hm, maybe simply "listed > first in the doc"). I think it would make things easier and clearer to first > discuss the things that are exposed by the abstract APIs today. > SCTP will help, then: it exposes "reliable". So if we'd go with that, the > first item in your list above for TCP would already disappear from the > discussion: it will eventually need to be exposed by a TAPS system because of > SCTP anyway, and thus belongs in the list. > > So if the document would, for instance, first list all the things that the > protocol's abstract API now expose, and then follow with static properties > that protocols have (and that a certain combination of chosen services would > entail), then that list of static properties gets shorter - e.g., for TCP, > from the two items above, only "byte stream" would be left. Structuring the things are a good idea. Which do you get "byte stream", not "reliable byte stream"? > > My aim here is to try to simplify things so that we can gradually make > progress rather than beginning by discussing a long list where it's very hard > to argue for why one particular bit should be in the list or not. If folks > things I'm not making it easier but harder, please ignore me :-) I'm only > trying to help... Great. Me too. Just trying to understand which things should be listed in a coherent way...
Best regards Michael > > Cheers, > Michael > > _______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
