> On 05 Jun 2015, at 22:17, Michael Welzl <[email protected]> wrote: > > >> On 5. jun. 2015, at 19.52, Michael Tuexen <[email protected]> >> wrote: >> >>> On 05 Jun 2015, at 16:03, Michael Welzl <[email protected]> wrote: >>> >>> >>>> On 05 Jun 2015, at 15:52, Michael Tuexen >>>> <[email protected]> wrote: >>>> >>>>> On 05 Jun 2015, at 15:39, Michael Welzl <[email protected]> wrote: >>>>> >>>>> >>>>>> On 05 Jun 2015, at 12:35, Michael Tuexen >>>>>> <[email protected]> wrote: >>>>>> >>>>>>> On 05 Jun 2015, at 11:05, Michael Welzl <[email protected]> wrote: >>>>>>> >>>>>>> >>>>>>>> On 5. jun. 2015, at 10.12, Mirja Kühlewind >>>>>>>> <[email protected]> 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"? > > Only "byte stream" because you don't need to talk about reliability anymore > when you have it covered by going through the abstract APIs. OK. So are talking about an abstract API for all protocols, not about an abstract API for a particular protocol, right? Furthermore you are saying that the abstract API does provide a specification of the level reliability, but not of byte stream vs message oriented?
Thanks for helping me to get things clear... Best regards Michael > > Then, of course, things are tied to certain protocols ... after all TCP *IS* > reliable so when you pick it e.g. for the byte stream (or perhaps MPTCP's > functions) you always get reliability with it. But then, certain mechanisms > are semantically compatible in a best effort world - e.g. an application > asking for unreliable data transfer will not break if it gets reliability > (it's just slower). This kind of match-making between the services and > protocols might become easier if we first have a list of what protocols > provide to upper layers, and then have the static properties per protocol > MINUS the things in the first list. That's all I'm suggesting. > > Cheers, > Michael > > _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
