Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt

From: Michael Welzl <[email-masked]>
Date: Mon, 1 Jun 2015 12:23:30 +0300

> On 1. jun. 2015, at 03.17, Olivier Mehani <[email-masked]> wrote:
> 
> Hey Mirja,
> 
> On Fri, May 29, 2015 at 10:27:46AM +0200, Mirja Kühlewind wrote:
>>> I am not sure I have the same understanding of what features are.
>>> More than what is exposed through the API (which indeed is very
>>> little in the majority of the cases), I think features is what the
>>> application implicitly expects when selecting a specific transport.
>> Yes and no. So what you describe is the current state. A transport
>> service is a set of transport services features and today you can
>> select those features only implicitly by selection the transport
>> protocol itself.
>> However, I think that it is worth to provide an interface to configure
>> each feature explicitly. Not completely sure yet that it is true. But
>> for me that’s one of the goals of this working group to figure out if
>> this statement is true.
> 
> Yes, that's how I understand it too. Nonetheless, we need to start with
> what we have: groups of features that we need to identify and separate.
> 
>>> At the moment, looking at the draft, I think that most “Transport
>>> Protocol Components” sections actually conflate features and components,
>>> and probably list more of the former than the latter. I don't think this
>>> is quite in line with the terminology:
> [...]
>>> 
>>> For example for TCP, I would say that the following are features (that the application wants)
>>> - reliable delivery
>>> - ordered delivery for each byte stream
>>> - stream-oriented delivery in a single stream
>>> - unicast
>>> - data bundling (Nagle's algorithm)
>>> - port multiplexing
>>> while these are components (that the application doesn't see)
>>> - connection setup with feature negotiation and application-to-port mapping
>>> - error detection (checksum)
>>> - segmentation
>>> - flow control
>>> - congestion control
>> I also see this very slightly different. Features and components are
>> for my understanding nothing exclusive. Each feature also has a
>> corresponding component (but not the other way around). However, while
>> the feature is ‚reliable delivery‘ (because that all the app cares
>> about), the component might be more specific like "reliable delivery
>> using accumulated ACKs and retransmissions’ as TCP does.
> 
> Yes, I completely agree. But I think the difference you higlight is
> important: each feature has one (or more, I'd say) corresponding
> components, while components might not necessarily result in an
> application-visible feature. 
> 
>> The more important point is, that the current lists in the doc need
>> work! Maybe some of the point you’ve listed above as features must be
>> phrased more detailed to describe/list the actually component and then
>> we need to decide which components actually also provide a feature
>> (that should be exposed) and on which level this correlates to a
>> feature. So the split you proposed above is a good starting point for
>> this.
> 
> I'm glad to read it (:
> 
>>>> "transport service features"  (components that are exposed to the
>>>> application) ... and here come all the things found in today's (not
>>>> tomorrow's!) APIs, as defined by the specs alone, not
>>>> implementations and "transport protocol components"  ... which is
>>>> all the rest. I'm thinking of just a way of splitting the component
>>>> lists, just to say "the following ones are exposed in the API
>>>> today".
>>> I think this makes sense. That said, beyond just the specs, I think
>>> it would be useful to consider what current implementations provide
>>> too, as this may offer a slightly different set of features which
>>> is, nonetheless, what developers of real applications are dealing
>>> with.
>> You mean it term of APIs or component? Collecting information of
>> components are are currently implemented/used is the purpose of this
>> doc. Collecting information about API/config interfaces of what is
>> implemented/used today is also useful but a rat-hole… therefore we try
>> cover this aspect briefly in this doc but do not aim for completeness
>> here.
> 
> Yes, this is likely for a later document. However, I think we should
> make sure that some transport API have not implemented some
> non-standardised behaviours that a non-negligible number of applications
> use. I am not sure it's the case, but if it is so, we probably want to
> take that onboard at some point too.

I'd like to stress "at some point"  (if at all).  Maybe not even in this particular document?

This is exactly the layering problem here - transport protocol designers will have thought through what kind of information should be exposed. App programmers are now facing today's systems that they need to optimize as good as they can. Maybe ad hoc decisions are / were made to allow some protocol tuning that shouldn't really be an application's problem.

To me, apps fine tuning protocols in non-standard ways is already one small step in the direction of what TAPS is trying to help against: every application programmer re-doing the job again, developing their own transport protocols inside their app.

I think it's important to start with what the protocol designers thought should be exposed and no more, and then we can draw a clean line and say "look, maybe these decisions should be revisited, this and this is constantly being used by applications".

Cheers,
Michael

---

From: Mirja Kühlewind <[email-masked]>
Date: Mon, 1 Jun 2015 15:32:03 +0200

Hi Joe, hi Michael,

I completely welcome to add more text to the Interface description section (3.1.2). Currently this section is very short and says regarding the (higher layer) interface described in FRC793:

"A User/TCP Interface is defined in [RFC0793] providing six user
   commands: Open, Send, Receive, Close, Status.  This interface does
   not describe configuration of TCP options or parameters beside use of
   the PUSH and URGENT flags.“

This text was already added based on Joe’s input. Please provide more text if you think this is not sufficient. 

Probably we should at least add one more sentence describing the TCP-to-User interface (as it is called in RFC 793) like this:

„Further the TCP-to-User interface is described providing information on the local connection name, the response string, the send and received buffer addresses, the Byte count (which counts bytes received) as well as the PUSH flag and URGENT flag.“

However, from my point of view I actually think that these (basic) things do not need to be discussed in more detail because the described interface is completely okay and can probably be mostly say as it is. The more complicated question is which additional things are needed and, even more important, how can you design a transport interface where the application does not need to choose the protocol first. Because the interface in RFC 793 only describes a User/TCP interface where TCP already determines a certain transport service or a set of transport services features relating to specific transport components. The whole goal or taps is to make things more flexible which mean we need more information before we open a connection and probably also during the connection. One information could be „I want to use a TCP header“ and maybe together with these features… However, as soon as we have chosen certain protocol which might be TCP be still need Open, send, receive and closes commands as described in RFC 793.

So what I want to say is, that the described interface in RFC 793 is so basic that it is not wrong and should be described in this doc (as it is) but it does help us very much to get to the goal we would like to reach in taps which I currently would describe as: Extend the application layer interface to consequently provide a more flexible transport layer. Or even better the other way around: Create a more flexible transport layer which most likely will lead to an extended application-level interface.

Another thing I also would like to say (again) at this point is that the current doc will not specify an new interface. We on purpose ‚only‘ talk about transport components and features in this document because we first need to know what we want to do before we can talk about the interface.

However, again, if you think there is something important missing in this doc, please send text!
Currently we will (more or less) just integrate all text that we get because it is much easier to discuss about text that is there and something that is not there. That does also mean that any text that is currently in the doc can be discussed, changed or removed!

Mirja

> Am 30.05.2015 um 14:24 schrieb Michael Welzl <[email-masked]>:
> 
> 
>> On 29. mai 2015, at 19.32, Joe Touch <[email-masked]> wrote:
>> 
>> First, I think this discussion would benefit from a clarification of
>> what "API" means, or at least to stop using that term in isolation.
>> 
>> There are three distinct concepts:
>> 
>> 	A- abstract protocol "upper layer interface"	
>> 		e.g., OPEN, CLOSE, ABORT, as per RFC 793
>> 
>> 	B- programmer API
>> 		e.g., Linux C/C++ TCP socket interface
>> 
>> 	C- instance of a programmer API
>> 		e.g., Linux Ubuntu 15.04 C/C++ TCP socket interface
>> 
>> IMO, this document MUST discuss A, and can be address potential
>> extensions to A based on examining variants of B and C.
>> 
>> There are also the protocol features, which are the properties of the
>> protocol that:
>> 	- can be explicitly configured and monitored
>> 		these are *exactly* A, B, and/or C above
>> 
>> 	- can be implicitly detected
>> 		some are based on the definition of the protocol,
>> 		such as reliable, byte sequence delivery
>> 
>> 		some are an artifact of the implementation,
>> 		such as specific delays due to burst losses
>> 
>> However, *none* of this is a rat-hole IF TAPS is intended to explain the
>> service interface to the user. IMO, B and C above should be secondary
>> considerations after A is clearly documented, but this draft is a long
>> way from that.
> 
> I agree: A should be there, and it should probably the primary focus, as starting with a list of A would add a lot of clarity to the document and the discussion of it.
> 
> Some text on protocol internals, explaing what a protocol does even though these things may not be exposed to an application, can be valuable even if only to know which protocol to choose. So I'm not suggesting removing everything but I'd agree that the focus of the document should shift towards a list of A.
> 
> Cheers,
> Michael

---

From: Michael Welzl <[email-masked]>
Date: Mon, 1 Jun 2015 19:45:13 +0300

> On 1. jun. 2015, at 16.32, Mirja Kühlewind <[email-masked]> wrote:
> 
> Hi Joe, hi Michael,
> 

I agree

> However, from my point of view I actually think that these (basic) things do not need to be discussed in more detail because the described interface is completely okay and can probably be mostly say as it is.

I agree

> The more complicated question is which additional things are needed and, even more important, how can you design a transport interface where the application does not need to choose the protocol first. Because the interface in RFC 793 only describes a User/TCP interface where TCP already determines a certain transport service or a set of transport services features relating to specific transport components. The whole goal or taps is to make things more flexible which mean we need more information before we open a connection and probably also during the connection.

True, but this sounds out of scope of this document? This is just supposed to list the services...

> One information could be „I want to use a TCP header“ and maybe together with these features… However, as soon as we have chosen certain protocol which might be TCP be still need Open, send, receive and closes commands as described in RFC 793.

I'd say "I want to use a TCP header" should definitely be out of scope of all this because it defeats the purpose of the TAPS idea. If I know I want to use a TCP header, I don't use TAPS, I use TCP!  We're not aiming at replacing the interface for all applications, just offering something new.

> So what I want to say is, that the described interface in RFC 793 is so basic that it is not wrong and should be described in this doc (as it is) but it does help us very much to get to the goal we…

Yes, but...

> Another thing I also would like to say (again) at this point is that the current doc will not specify an new interface.

Exactly  :-)

> We on purpose ‚only‘ talk about transport components and features in this document because we first need to know what we want to do before we can talk about the interface.
> 

Good, thanks. Anyway my point was that, in this list of services, we should be clear about Joe's item A: what is currently offered to apps by the current specs. This is the most important part of the list because it reflects what designers of these protocols (and with them, some form of prior IETF group consensus) think should be offered to apps.

Going beyond that by discussing internals or things that some apps now can tune is a nice extra perhaps, but I think it should be a secondary goal.

Cheers,
Michael

---

From: Joe Touch <[email-masked]>
Date: Mon, 01 Jun 2015 09:55:40 -0700

>> „Further the TCP-to-User interface is described providing information on the local connection name, the response string, the send and received buffer addresses, the Byte count (which counts bytes…

My concern is that there is no clear relation between 3.1.2 and 3.1.3.

In fact, many of the properties of 3.1.3 are the result of the interface
mentioned in 3.1.2. Also, a few aspects of the 3.1.2 interface aren't
considered in 3.1.3.

So what's the point of 3.1.3?

>From the definition:
   Transport Protocol Component:  an implementation of a transport
      service feature within a protocol.

Unfortunately, the items in 3.1.3 aren't implementations; they're
general properties. An implementation would be Reno or CUBIC.

In addition, API isn't defined (e.g., see my previous 3 descriptions),
so it's never clear what should be in 3.1.2 (or the corresponding
sections of other protocols).

As a result, I do not understand the purpose of either section of this
document, or this document as a whole.

Joe

---

From: Mirja Kühlewind <[email-masked]>
Date: Mon, 1 Jun 2015 20:38:17 +0200

Hi Joe
> My concern is that there is no clear relation between 3.1.2 and 3.1.3.

Yes, that’s actually true. Initially there was no section 3.1.2 as this doc is not on interfaces. However it seems to be incomplete without mentioning interfaces at all. If we keep this section, you are right, the relation should be there.

> mentioned in 3.1.2.

Really? Can you give an example? I would rather hope that we can describe the transport components independent of the currently/any interface.

> Also, a few aspects of the 3.1.2 interface aren't
> considered in 3.1.3.

To complete 3.1.3, looking at interface is probably useful. Can you list what’s missing?

> So what's the point of 3.1.3?

I’d rather ask what’s the point of 3.1.2…? 3.1.3 is/should become a list of components as basis for discuss which features should/must be exposed to the app-layer. 

> general properties. An implementation would be Reno or CUBIC.

I agree that what’s currently listed is not on the right level of detail (see also my other mail to Olivier). Not sure if Reno/Cubic is on the right level either. Maybe it’s delay/loos-based or foreground/background or AIMD, but congestion control is especially complicated I’d say. That’s what we have to figure out now.

> sections of other protocols).

I don’t know either what should be in 3.1.2 right now. Anything that is useful for 3.1.3 or 4 should be mentioned; everything else will be removed at the end (potentially even the whole section). 

> document, or this document as a whole.

That’s to bad. Maybe we should state this more explicitly in the intro…? According to our charter, while taps itself is chartered to describe "an (abstract) interface for applications 
to make use of Transport Services“, this first document is only used to "identifying the 
[components] provided by existing IETF protocols“ as a starting point. Further we would like to add some discussion in section 4 which of the identified components should/can be exposed as a transport feature that the app should see. [Note that the terminology changed and whenever services is written in the charter it should basically be component.]

Does this help?

Mirja

> 
> Joe
> 
> _______________________________________________
> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps

---

From: Joe Touch <[email-masked]>
Date: Mon, 01 Jun 2015 11:55:49 -0700

On 6/1/2015 11:38 AM, Mirja Kühlewind wrote:
> Yes, that’s actually true. Initially there was no section 3.1.2 as
> this doc is not on interfaces. However it seems to be incomplete without
> mentioning interfaces at all. If we keep this section, you are right,
> the relation should be there.

Interfaces *define* services:

	We use the term "Transport
	Service" to mean an end-to-end facility provided by the
	transport layer. That service can only be provided correctly if
	information is supplied from the application.

The API defines the information supplied from (and to) the application.

Thus, if TAPS doesn't include the API in its flagship document, then I
have no idea what you're all doing.

> Really? Can you give an example? I would rather hope that we can
> describe the transport components independent of the currently/any
> interface.

Your own charter indicates why that is not possible.

(Again, I mean "abstract API", not the C or Linux implementations of these).

Properties:

	- stateful
		result of OPEN and CLOSE commands

	- active calling party
		result active/passive OPEN commands
		i.e., one party needs to actively call the other

	- byte-oriented, in order
		result of SEND/RECEIVE calls in order
		that input/output blocks of bytes in linear
		sequence

	- independent of the application data boundaries
		result of the semantics fo the SEND/RECEIVE
		calls, which input/output blocks of bytes
		where the call data boundaries are defined as NOT
		corresponding to TCP segment boundaries or events

	- OOB signaling
		result of PUSH and URG interface

> To complete 3.1.3, looking at interface is probably useful. Can you list what’s missing?

I've done this multiple times already.

> I’d rather ask what’s the point of 3.1.2…? 3.1.3 is/should become a
> list of components as basis for discuss which features should/must be
> exposed to the app-layer.

The list of "components" doesn't fit the definition within this doc, so
I disagree with this.

> I agree that what’s currently listed is not on the right level of
> detail (see also my other mail to Olivier). Not sure if Reno/Cubic is on
> the right level either. Maybe it’s delay/loos-based or
> foreground/background or AIMD, but congestion control is especially
> complicated I’d say. That’s what we have to figure out now.

You need to update your definitions first if that's the case.

> I don’t know either what should be in 3.1.2 right now. Anything that is
> useful for 3.1.3 or 4 should be mentioned; everything else will be
> removed at the end (potentially even the whole section).

The expectations for what are in each section should be defined in this
document.

Again, if we all don't know what's being written, writing is premature.

> That’s to bad. Maybe we should state this more explicitly in the
> intro…? According to our charter, while taps itself is chartered to
> describe "an (abstract) interface for applications
> to make use of Transport Services“,

That is an API - more specifically, it's a future, desired abstract API.

> this first document is only used to "identifying the
> [components] provided by existing IETF protocols“ as a starting
> point.

IMO, you need to start by defining the current abstract API, then the
internal capabilities (independent of implementation) that might be exposed.

I don't see how to do that with this "shopping-list" of issues.

Joe

---

From: Michael Welzl <[email-masked]>
Date: Mon, 1 Jun 2015 22:12:37 +0300

> [components] provided by existing IETF protocols“ as a starting point. Further we would like to add some discussion in section 4 which of the identified components should/can be exposed as a transp…

This confuses me.

draft-ietf-taps-transports-04 defines a "Transport Protocol Component" as "an implementation of a transport service feature within a protocol."
I'm fine with that definition but I can't see why this should replace "service" in the charter. The first document should list the services provided by existing IETF protocols, that's how to get started. Additionally listing components is probably fine if that helps explaining how services are constructed, but the focus is on what transports provide - services.

Cheers,
Michael

---

From: Michael Welzl <[email-masked]>
Date: Mon, 1 Jun 2015 22:23:14 +0300

I'll try addressing another detail, maybe that helps get us aligned:

> On 1. jun. 2015, at 21.38, Mirja Kühlewind <[email-masked]> wrote:
> 
> Hi Joe
>> 

The document is about services. These are provided via interfaces - so the document should very much be about interfaces.
3.1.3 describes TCP, it lists all the things you get with TCP - nothing that the application can configure, but what you get with it anyway.

The complete service provided by TCP consists of everything TCP is AND the what the application can configure about it.
It gives you segmentation, congestion control, .... AND it lets you use PUSH and an URGENT pointer and ...

Cheers,
Michael

---

From: Joe Touch <[email-masked]>
Date: Mon, 01 Jun 2015 13:17:32 -0700

> The complete service provided by TCP consists of everything TCP is AND the what the application can configure about it.

Yes.

> It gives you segmentation, congestion control, .... AND it lets you use PUSH and an URGENT pointer and ...

Segmentation is HOW TCP gives you a reliable byte-sequence service over
a packet service.

It is absolutely NOT something provided to the user or under user
control. Users can set MTU values on *some systems*, but that's not part
of the TCP API (to the application) nor does MTU necessarily correspond
to actual data boundaries (TCP is allowed to do a lot of things).

Joe

---

From: Michael Welzl <[email-masked]>
Date: Mon, 1 Jun 2015 23:34:46 +0300

> On 1. jun. 2015, at 23.17, Joe Touch <[email-masked]> wrote:
> 
> 
> 

Yes, I didn't mean that segmentation is under user control. Let me rephrase my above sentence:

>> It gives you, via its non-configurable static behavior: segmentation, congestion control, .... AND it lets you control some things: PUSH and an URGENT pointer and ...

Cheers,
Michael

---

From: Joe Touch <[email-masked]>
Date: Mon, 01 Jun 2015 14:22:15 -0700

On 6/1/2015 1:34 PM, Michael Welzl wrote:
....
>>> It gives you, via its non-configurable static behavior:
>>> segmentation, congestion control, .... AND it lets you control some
>>> things: PUSH and an URGENT pointer and ...

But it doesn't "give" you segmentation. It uses segmentation to provide
a reliable byte stream over a packetized service. If we wanted, we could
arguably export a TCP service over a circuit that did NOT need to rely
on segmentation.

This discussion really needs to distinguish between WHAT TCP exports and
HOW TCP makes that happen - the latter may or may not ever be visible to
the user.

Joe

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Tue, 2 Jun 2015 06:13:29 +0000

I agree with your last statement. We must find a way to distinguish between the features that an application may require and network functionalities that derive from those features. 

Marie-Jose Montpetit, Ph.D.
[email-masked]
@SocialTVMIT

> On Jun 1, 2015, at 11:22 PM, Joe Touch <[email-masked]> wrote:
> 
> 
>

---

From: Aaron Falk <[email-masked]>
Date: Tue, 2 Jun 2015 10:58:14 -0400

IMO, this has been an interesting and valuable discussion.  One takeaway
(for me) is that we have been sloppy in using the terms "interface" as well
as "implementation".  I think there has been some clarification on the need
to document the "interface" for transport protocols.  I would further
suggest avoiding the term "implementation" which sometimes is used to mean
"translate a feature to a mechanism"  and sometimes "translate a mechanism
to code".  Joe's definition of the various meanings of API raise this.

--aaron

On Tue, Jun 2, 2015 at 2:13 AM, Marie-Jose Montpetit <[email-masked]>
wrote:

> I agree with your last statement. We must find a way to distinguish
> between the features that an application may require and network
> functionalities that derive from those features.
>
>
>

---

From: Mirja Kühlewind <[email-masked]>
Date: Fri, 05 Jun 2015 10:12:50 +0200

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'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 ...").

Mirja

---

From: Michael Welzl <[email-masked]>
Date: Fri, 5 Jun 2015 11:05:00 +0200

> On 5. jun. 2015, at 10.12, Mirja Kühlewind <[email-masked]> 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.

That's why I think the service is more important than the component, and that's why I'm on Joe's side here.

Cheers,
Michael

---

From: Michael Welzl <[email-masked]>
Date: Fri, 5 Jun 2015 11:19:25 +0200

Sorry for sending an extra email - I just had an extra thought and think this is important to add:

Below:

> On 5. jun. 2015, at 11.05, Michael Welzl <[email-masked]> wrote:
> 
> 

as Brian pointed out in a previous email, a protocol comes with a series of what he called "positive properties" and "negative properties". Anyway, properties: your application may like some and hate some. It's always a suite of properties - then, we probably can't expose them individually - e.g. with today's protocols, you can't get MPTCP's usage of multiple paths with coupled congestion control but at the same time have SCTP's strong CRC.

Sure, we can say the same about combinations of things that are currently being offered in the abstract APIs of the protocols, but still, things will get easier there: the list is shorter, it's clearer what we need to include and what not (basically everything must be included), and certain API elements will clearly dictate which protocol(s) to use. Therefore I do believe that the job gets much easier if we focus on the abstract APIs first. I'm not against listing the components, it's about what matters more (and it should be reflected in the document accordingly - maybe it could even be an idea to split the document in two, one purely about the "abstract API" and one about "components", and possibly merge them later?).

Cheers,
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 5 Jun 2015 12:35:41 +0200

> On 05 Jun 2015, at 11:05, Michael Welzl <[email-masked]> wrote:
> 
> 
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.

Best regards
Michael

---

From: Mirja Kühlewind <[email-masked]>
Date: Fri, 05 Jun 2015 13:29:19 +0200

Hi Michael,

see below.

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

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.

> 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

-- 
------------------------------------------
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-masked]
------------------------------------------

---

From: Michael Welzl <[email-masked]>
Date: Fri, 5 Jun 2015 15:34:48 +0200

> On 05 Jun 2015, at 13:29, Mirja Kühlewind <[email-masked]> wrote:
> 
> Hi Michael,
> 
> see below.
> 
> 
> 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 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.

Cool, thanks for the work you folks put into this! And have a nice weekend,
Michael

---

From: Michael Welzl <[email-masked]>
Date: Fri, 5 Jun 2015 15:39:38 +0200

> On 05 Jun 2015, at 12:35, Michael Tuexen <[email-masked]> wrote:
> 

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.

Cheers,
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 5 Jun 2015 15:52:22 +0200

> On 05 Jun 2015, at 15:39, Michael Welzl <[email-masked]> wrote:
> 
> 
Such as "reliable" for TCP? Or "byte stream" for TCP? These properties come with choosing TCP...

Best regards
Michael

---

From: Michael Welzl <[email-masked]>
Date: Fri, 5 Jun 2015 16:03:45 +0200

> On 05 Jun 2015, at 15:52, Michael Tuexen <[email-masked]> wrote:
> 

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.

My aim here is to try to simplify things so that we can gradually make progress rather than beginning by discussing a long list where it's very hard to argue for why one particular bit should be in the list or not. If folks things I'm not making it easier but harder, please ignore me  :-)    I'm only trying to help...

Cheers,
Michael

---

From: Joe Touch <[email-masked]>
Date: Fri, 05 Jun 2015 09:45:14 -0700

On 6/5/2015 4:29 AM, Mirja Kühlewind wrote:
> 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...?

Perhaps "flagship" isn't a useful word for either doc.

IMO, this is a "foundation" doc, and as such needs to set the groundwork
for other docs.

As to what doc we'll point people at when this is done, that could be a
BCP, it could be a new protocol (experimental, presumably), etc.

But we're nowhere near understanding what that last doc will be if we
can't agree on what a protocol or API is.

Joe

---

From: Christian Huitema <[email-masked]>
Date: Fri, 5 Jun 2015 17:31:04 +0000

On Friday, June 5, 2015 6:40 AM, Michael Welzl wrote:
>
> ... 
> 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.

I don't think that applications care very much about the distinction between CRC32 and 16 bit checksum. The real distinction is between "some protection" and "cryptographic protection," as given for example by SSL/TLS on top of TCP. Obviously the 16 bit checksum 16 will let through more transmission errors than the 32 bit CRC, but errors can also happen "above" the checksum, during the various data manipulations performed by the transport protocols. They can also be due to overactive middleboxes that will change the data and then "fix" the checksum. Applications that are concerned enough about the integrity of the data are going to use crypto end-to-end.

Which is an argument for taking a view of service definitions "from the application," rather than merely cataloging what TCP and SCTP can do today.

-- Christian Huitema

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 5 Jun 2015 19:52:16 +0200

> On 05 Jun 2015, at 16:03, Michael Welzl <[email-masked]> wrote:
> 
> 
Structuring the things are a good idea. Which do you get "byte stream", not "reliable byte stream"?
> My aim here is to try to simplify things so that we can gradually make progress rather than beginning by discussing a long list where it's very hard to argue for why one particular bit should be in…
Great. Me too. Just trying to understand which things should be listed in a coherent way...

Best regards
Michael

---

From: Michael Welzl <[email-masked]>
Date: Fri, 5 Jun 2015 22:17:44 +0200

> On 5. jun. 2015, at 19.52, Michael Tuexen <[email-masked]> wrote:
> 

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

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 5 Jun 2015 22:39:07 +0200

> On 05 Jun 2015, at 22:17, Michael Welzl <[email-masked]> wrote:
> 
> 
OK. So are talking about an abstract API for all protocols, not about an abstract API for a particular protocol, right?
Furthermore you are saying that the abstract API does provide a specification of the level reliability, but not of byte stream vs message oriented?

Thanks for helping me to get things clear...

Best regards
Michael

---

From: Anna Brunstrom <[email-masked]>
Date: Sat, 06 Jun 2015 00:12:26 +0200

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

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

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Sat, 6 Jun 2015 04:37:36 +0000

I completely agree.

> On Jun 6, 2015, at 12:12 AM, Anna Brunstrom <[email-masked]> wrote:
> 
> 
> 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
>>

---

From: Michael Welzl <[email-masked]>
Date: Sat, 6 Jun 2015 11:47:31 +0200

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 <[email-masked]> wrote:
> 
> I completely agree.
>