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
