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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
