Hi Michael,
see below.
On 05.06.2015 11:05, Michael Welzl 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 don't think that this decision is (in general) that easy. That's why we go
through the exercise of decomposing existing protocols into their components and
based on this information discuss what potentially could be exposed and further
reason about what should be exposed (because there are implications for the
application).
From my point of view this process it independent of the interface (not matter
if we talk about an abstract interface, a certain implementation or what we want
to have in future). However, looking at current interfaces will probably help us
to make the right decisions.
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.
That's why I think the service is more important than the component, and that's
why I'm on Joe's side here.
I didn't say anything about the importance of anything. I think all three
documents and and all kind of transport 'things' we talk about are important.
And most important is the process of getting things 'decomposed' correctly and
discussed in the right document at the right time.
What I wanted to say is that people who later on read these docs (because they
want to use taps), probably only read the third doc, maybe the second, and very
likely will only read this document if they already have read the other two and
would like have additional information.
I do have the feeling that parts of what Joe wants to discuss should however be
in the third doc. And therefore I think that the current first doc is not the
taps flagship doc because for me a flagship doc (and we probably need to define
this term ;-) ) is the doc that you point people to as the first thing to read
after the work was finished...?
All in all, I actually think that we are on the same side here (and right at
this point we don't need too much further discussion). Brian and I are in the
process of marking a better distinction on components and feature than what is
given in the lists in the current version. I believe the current, very sloppy
handing of these lists is where most on the confusion (and potentially
disagreement) comes from and I hope that discussion can be more focused soon as
we have submitted the next revision.
Mirja
Cheers,
Michael
--
------------------------------------------
Dipl.-Ing. Mirja Kühlewind
Communication Systems Group
Institute TIK, ETH Zürich
Gloriastrasse 35, 8092 Zürich, Switzerland
Room ETZ G93
phone: +41 44 63 26932
email: [email protected]
------------------------------------------
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
