I do, too - I didn't mean that we should merge the abstract APIs together right now, in this first doc! This was just about the thought process - while my answer to Michael Tuexen is "yes, I meant the complete abstract API", that was just about what we could eventually get from having a complete view of this API.
> On 6. jun. 2015, at 06.37, Marie-Jose Montpetit <mari...@mit.edu> wrote: > > I completely agree. > > Marie-Jose Montpetit, Ph.D. > mari...@mit.edu > @SocialTVMIT > >> On Jun 6, 2015, at 12:12 AM, Anna Brunstrom <anna.brunst...@kau.se> wrote: >> >> >> On 2015-06-05 22:17, Michael Welzl wrote: >>>> On 5. jun. 2015, at 19.52, Michael Tuexen >>>> <michael.tue...@lurchi.franken.de> wrote: >>>> >>>>> 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"? >>> Only "byte stream" because you don't need to talk about reliability anymore >>> when you have it covered by going through the abstract APIs. >>> >>> 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. >> >> Even if there will be some overlap, I think it will be more clear to >> describe the abstract API and the static properties per protocol. This is >> what a protocol provides to upper layers and it will make the description of >> each protocol self-contained. The static properties are not that many and we >> can still make a clear distinction between the abstract API and the static >> properties in the description of each protocol. >> >> For the continued work it will also be useful to have a complete and agreed >> upon view of what each protocol provides. >> >> Cheers, >> Anna >> >>> >>> Cheers, >>> Michael >>> >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >> >> >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps _______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
