> 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. 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
