Subject: [Taps] TCP components

From: Mirja Kühlewind <[email-masked]>
Date: Thu, 11 Jun 2015 13:52:46 +0200

Hi all,

we gave it a first try to rewrite the component section for TCP. The insight I 
took from the discussion on the list is that components probably are much more 
linked to the implementation (choices) a certain protocol made while features 
are probably more high-level having the question in mind what does an 
application potentially want/need to know.

So for the components in TCP we now have the following list:

- Connection-oriented bidirectional communication using three-way handshake 
connection setup with
	feature negotiation and an explicit distinction between passive and active open:
  	This implies both unicast addressing and a guarantee of return routability.
- Single stream-oriented transmission:
	The stream abstraction atop the datagram service provided by IP is implemented 
by dividing
	the stream into segments.
- Limited control over segment transmission scheduling (Nagle's algorithm):
	This allows for delay minimization in interactive applications.
- Port multiplexing, with application-to-port mapping during connection setup:
	Note that in the presence of network address and port translation (NAPT), TCP 
ports are
	in effect part of the endpoint address for forwarding purposes.
- Full reliability based on ack-based loss detection and retransmission:
	Loss is sensed using duplicated acks ("fast retransmit"), which places a lower 
bound on
	the delay inherent in this approach to reliability.
- Error detection based on a checksum covering the network and transport headers 
as well as payload:
	Packets that are detected as corrupted are dropped, relying on the reliability 
mechanism
	to retransmit them.
- Window-based flow control, with receiver-side window management and signaling 
of available window:
	Scaling the flow control window beyond 64kB requires the use of an optional 
feature,
	which has performance implications in environments where this option is not 
supported.
- Window-based congestion control reacting to loss, delay, retransmission 
timeout, or
	an explicit congestion signal (ECN):
	Most commonly used is a loss signal from the reliability component's 
retransmission mechanism.
	TCP reacts to a congestion signal by reducing the size of the congestion window;
	retransmission timeout is generally handled with a larger reaction than other 
signals.

We are currently still working on the list of features that results from thiese 
components but we are not there yet. Probably we not only need the features 
itself but also properties/aspects (or however you want to call this) of the 
feature. We already had this discussion a bit but wanted to postpone the 
decision if we really need to define an own term for this until we are sure that 
we need it.

We are posting this list of (TCP) components now because we would like to get 
some feedback if this goes into the right direction/is on the right level of 
detail before we go on and apply this also to other protocols.

Brian and Mirja

---

From: [email-masked]
Date: Thu, 11 Jun 2015 13:30:37 +0100

> 	This allows for delay minimization in interactive applications.

GF: Not quite - To me, it prevents increased delay from the TCP protocol.
It doesn't really control anything to reduce delay.

> - Port multiplexing, with application-to-port mapping during connection

GF: Thinking on this, is application-to-port mapping really a TCP
function? port-mapping is similar in other transports, and doesn't really
have any different support in TCP (contrast to the Service Code in DCCP)

> 	in effect part of the endpoint address for forwarding purposes.
GF: This is the case only for those middle boxes that do NAPT,
load-ballancing etc, saying they are part of the endpoint address is to me
confusing forwarding by middle boxes from forwarding by routers - I'd
prefer to be more careful here.

> 	the delay inherent in this approach to reliability.
GF: DupACK, SACK, and the RTO. (explicit NACK is I think only used in
SCPS-TP and probably doesn't nee dot be mentioned).

> 	Packets that are detected as corrupted are dropped, relying on the
GF: True (actually packets header checks and data segments + pseudo header)

> 	which has performance implications in environments where this option is
GF: Does environment mean path? or something else?

> 	retransmission timeout is generally handled with a larger reaction than
> other  signals.
>
GF: Generally? Shouldn't RTO imply loss of path state and always result in
a larger reaction? (RTO back-off for instance).

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

---

From: Mirja Kühlewind <[email-masked]>
Date: Thu, 11 Jun 2015 16:11:41 +0200

Hi Gorry,

see below.

> It doesn't really control anything to reduce delay.

Yes, I think we wanted to say the same thing here; don't really see the 
difference...

> have any different support in TCP (contrast to the Service Code in DCCP)

No it's not specific to TCP but it's still something you get when you use TCP 
and that's what we wanted to document here.

> prefer to be more careful here.

I agree that we should be careful here about the wording. However this was only 
a note to explain slightly better what we had in mind here.

> SCPS-TP and probably doesn't nee dot be mentioned).

I'd say DupACK and RTO is both ACK-based loss detection where in the latter case 
no ACKs are received for a certain time. However we can add both explicitly 
here. What we probably should mention is that RTO puts a maximum bound on the 
delay. I agree that SACK should probably be mentioned as well here because this 
again helps speeding up the retransmissions and therefore helps reducing delay 
by head of line blocking.

> GF: True (actually packets header checks and data segments + pseudo header)

Sorry, what do you mean by pseudo header here?

> GF: Does environment mean path? or something else?

Both option stripping on the path or no support of the receiving end point. Can 
make this more clear.

> a larger reaction? (RTO back-off for instance).

In principle yes, but you could easily also implement an congestion control 
algorithm there the window is set to minimum for every dupACK. The 'generally' 
is because there is not the one and only congestion control in TCP and therefore 
you never know what people actually implement.

Mirja

---

From: [email-masked]
Date: Thu, 11 Jun 2015 15:24:38 +0100

We seem to agree mostly, a few small comments in-line

> No it's not specific to TCP but it's still something you get when you use
> TCP and that's what we wanted to document here.
>
So would we have the same text in UDP, SCTP, etc?
>>
>>> 	Note that in the presence of network address and port translation
>>> (NAPT),
>>> TCP
>>> ports are
> I agree that we should be careful here about the wording. However this was
> only a note to explain slightly better what we had in mind here.
>
>>
>>> 	Loss is sensed using duplicated acks ("fast retransmit"), which places
>>> a lower bound on
>>> - Error detection based on a checksum covering the network and
>>> transport
>>> headers
>>> as well as payload:
Only that TCP combines the segment data with the pseudo header from IP to
perform the checksum. For IPv4, this also assumes that each IP datagram
also passes the IP datagram checksum for each datagram (fragment)

>>> 	which has performance implications in environments where this option
>>> is
>>> not
>>> supported.
>>>
> Both option stripping on the path or no support of the receiving end
> point. Can make this more clear.
>
I'd prefer to be clear on this.
>>> 	TCP reacts to a congestion signal by reducing the size of the
>>> congestion
>>> window;
Gorry

---

From: Mohamed Oulmahdi <[email-masked]>
Date: Thu, 11 Jun 2015 16:36:43 +0200

Hi,

difference...

 I don't understand this delay optimization. Is it thanks to Nagle's
algorithm or for the possibility of its deactivation? Because it's known
that this algorithm increase delay and so became unsuitable for
delay-sensitive applications...
>
>
>>
>>>         Note that in the presence of network address and port
translation (NAPT),
> I agree that we should be careful here about the wording. However this
was only a note to explain slightly better what we had in mind here.
>>>         Loss is sensed using duplicated acks ("fast retransmit"), which
places a
>>> lower
> I'd say DupACK and RTO is both ACK-based loss detection where in the
latter case no ACKs are received for a certain time. However we can add
both explicitly here. What we probably should mention is that RTO puts a
maximum bound on the delay. I agree that SACK should probably be mentioned
as well here because this again helps speeding up the retransmissions and
therefore helps reducing delay by head of line blocking.
>>>         Packets that are detected as corrupted are dropped, relying on
the
>>> reliability
>>>         Scaling the flow control window beyond 64kB requires the use of
an
>>> optional
>>> feature,
>>>         which has performance implications in environments where this
option is
congestion
> In principle yes, but you could easily also implement an congestion
control algorithm there the window is set to minimum for every dupACK. The
'generally' is because there is not the one and only congestion control in
TCP and therefore you never know what people actually implement.

---

From: Mirja Kühlewind <[email-masked]>
Date: Thu, 11 Jun 2015 16:42:27 +0200

Hi Mohamed,

see below.

>> Yes, I think we wanted to say the same thing here; don't really see the difference...
>
>   I don't understand this delay optimization. Is it thanks to Nagle's  algorithm
> or for the possibility of its deactivation? Because it's known that this
> algorithm increase delay and so became unsuitable for delay-sensitive
> applications...

Yes, the delay is reduced if you deactivate it.

The component is the fact that there is an algorithm that will influence when
packets are sent (if data is available and the sending window is large enough).

Mirja

---

From: Joe Touch <[email-masked]>
Date: Tue, 16 Jun 2015 16:58:23 -0700

On 6/11/2015 5:30 AM, [email-masked] wrote:
...
> have any different support in TCP (contrast to the Service Code in DCCP)

The assumption of app-to-port mapping is part of how assigned ports are,
well, assigned.

> prefer to be more careful here.

Ports are part of the connection identifier, in conjunction with the
endpoint address.

The fact that NATs or any other devices remap, translate, or overload
that function (i.e., using it for forwarding decisions) is not relevant
to TCP's view of these values or to the service TCP provides, IMO.

Joe

---

From: Michael Welzl <[email-masked]>
Date: Wed, 17 Jun 2015 09:36:51 +0200

Hi,

> On 11 Jun 2015, at 13:52, Mirja Kühlewind <[email-masked]> wrote:
> 
> Hi all,
> 
> we gave it a first try to rewrite the component section for TCP. The insight I took from the discussion on the list is that components probably are much more linked to the implementation (choices) a certain protocol made while features are probably more high-level having the question in mind what does an application potentially want/need to know.
> 
> - Connection-oriented bidirectional communication using three-way handshake connection setup with
> 	The stream abstraction atop the datagram service provided by IP is implemented by dividing
> 	Note that in the presence of network address and port translation (NAPT), TCP ports are
> 	Loss is sensed using duplicated acks ("fast retransmit"), which places a lower bound on
> - Error detection based on a checksum covering the network and transport headers as well as payload:
> 	Packets that are detected as corrupted are dropped, relying on the reliability mechanism
> 	to retransmit them.
> - Window-based flow control, with receiver-side window management and signaling of available window:
> 	Scaling the flow control window beyond 64kB requires the use of an optional feature,
> 	which has performance implications in environments where this option is not supported.
> - Window-based congestion control reacting to loss, delay, retransmission timeout, or
> 	Most commonly used is a loss signal from the reliability component's retransmission mechanism.
> 	retransmission timeout is generally handled with a larger reaction than other signals.
> 
> We are currently still working on the list of features that results from thiese components but we are not there yet. Probably we not only need the features itself but also properties/aspects (or however you want to call this) of the feature. We already had this discussion a bit but wanted to postpone the decision if we really need to define an own term for this until we are sure that we need it.
> 
> We are posting this list of (TCP) components now because we would like to get some feedback if this goes into the right direction/is on the right level of detail before we go on and apply this also to other protocols.

I agree that the list below is closer to what I think a "component" should be ... but looking at it, is it not even clearer now that components are not what TAPS is after? To me this list now contains lots and lots of details that are irrelevant to the service provided to the application. Not harmful to list but pretty useless?!

And how do you draw the line for what goes in and out of such a list? E.g., on which basis did you decide that FACK, FRTO, PRR and DSACK are not mentioned?

To me, this whole thing is just too full of arbitrariness. We should aim for a systematic approach that minimizes the number of arbitrary decisions made IMO.

Cheers,
Michael

---

From: Mirja Kühlewind <[email-masked]>
Date: Wed, 17 Jun 2015 10:28:21 +0200

Hi Michael,

see below.

> Am 17.06.2015 um 09:36 schrieb Michael Welzl <[email-masked]>:
> 
> Hi,
> 
> 

In this case we decided to list/discuss rather some more details, so that people can understand what we had in mind. We might remove some of these details/explanations at the end (or move those parts that are actually relevant into the feature section (4)).

> And how do you draw the line for what goes in and out of such a list? E.g., on which basis did you decide that FACK, FRTO, PRR and DSACK are not mentioned?

We tried to ask ourself which parts have an effect on the behavior of the flow that could potentially be of interest for the application. We might have missed some points. Actually Gorry already point out some.

The next step is to work on the feature list and figure out how these things that are interesting for the application would be described in a more general way (independent of the concrete algorithm that is used by one protocol) and also discuss which features actually should be exposed because they have a real use for the application.

> To me, this whole thing is just too full of arbitrariness. We should aim for a systematic approach that minimizes the number of arbitrary decisions made IMO.

For us the systematic approach is to look at the implementation of existing protocol an figure out which algorithm have an influence on the traffic that might be interest for a higher layer to control. So we always had, to some extend, the application in mind. However, you could go for a even more generic approach and only look at the implementation and as a first step figure where are any knobs that in principle could be configurable and then afterwards discuss all of these very specific knobs. I though about this approach and think it would be an interest exercise and potentially the right way to go. But I also think that the overhead would be super large and I don’t think it would give us much more than we have right now. So we the current approach we might need to expect some arbitrariness…

Mirja

---

From: Michael Welzl <[email-masked]>
Date: Wed, 17 Jun 2015 10:44:57 +0200

> We tried to ask ourself which parts have an effect on the behavior of the flow that could potentially be of interest for the application. We might have missed some points. Actually Gorry already po…

Okay; btw just to be clear, I didn't mean that FACK etc. should be in the list - on the contrary! My point was really about "how do you draw the line", which you answered in the first sentence here.

> For us the systematic approach is to look at the implementation of existing protocol an figure out which algorithm have an influence on the traffic that might be interest for a higher layer to control. So we always had, to some extend, the application in mind.

Okay, I understand. Thanks for clarifying!

> However, you could go for a even more generic approach and only look at the implementation and as a first step figure where are any knobs that in principle could be configurable and then afterwards discuss all of these very specific knobs. I though about this approach and think it would be an interest exercise and potentially the right way to go. But I also think that the overhead would be super large and I don’t think it would give us much more than we have right now. So we the current approach we might need to expect some arbitrariness…

I lean towards this other one, of beginning with the knobs, but not with the implementation but rather the "abstract API" as Joe called it: the interface to the app as defined in the RFCs (for where it really *is* defined).

I think that this discussion with Joe maybe suffered from focusing on TCP. SCTP is perhaps a better starting point because it supports almost everything. So I'm thinking that a different (and, to me, perhaps more appropriate and more systematic) method to get a list of features could be to start with the read / write options in RFC 6458, extend it with all such options from the other protocols, and then, protocol by protocol, ask: "what does this protocol provide that the list now doesn't contain?". Not sure the overhead of this approach would be super large?  But I agree, you may end up with the same list the way you do it now.

Cheers,
Michael

---

From: Brian Trammell <[email-masked]>
Date: Wed, 17 Jun 2015 12:13:40 +0200

hi Michael, all,

A couple of random points inline at various levels of quotation...

> On 17 Jun 2015, at 10:44, Michael Welzl <[email-masked]> wrote:
> 
> 
>>> I agree that the list below is closer to what I think a "component" should be ... but looking at it, is it not even clearer now that components are not what TAPS is after? To me this list now contains lots and lots of details that are irrelevant to the service provided to the application.

That's part of the point we're trying to address here. The realization we had here is that components *don't* necessarily map to feature, and it's not clear that we can simply ignore those components that don't map, since they may have impact on the interfaces/features it is possible to (reasonably) implement atop those protocols.

>>> Not harmful to list but pretty useless?!

Let's start with TCP as probably the most difficult example (indeed, that's why we worked out this "new" arrangement of components for TCP first). A completely clean and unambiguous decomposition of TCP into its features -- what, I agree, we're after in the end -- is not *really* possible, because the protocols as defined and implemented weren't really composed of discrete features. The evolution of loss-based congestion control, for instance, was predicated on the particular loss signals that were available at the time it was first defined. The error detection mechanism likewise relies on the fact that reliability is provided by retransmission. One could say that given the parallel evolution of computing power that all these choices made by TCP were the only obvious ones at the time. But it's precisely the co-evolution of reliability and congestion control that makes gluing FEC to TCP so fraught with peril. That's an important point to capture IMO.

I expect that the same exercise for SCTP will show a simpler mapping between components and features, since it *was* designed as a composition of features.

> I lean towards this other one, of beginning with the knobs,

... understanding that interface definitions aren't just about which knobs (and indicators) the API provides, but also the interaction patterns it enables, and that these interaction patterns can also be made inefficient or even impractical by the details of the protocol in question. (It's always *possible* to implement object transfer over streams, or time domain transfer over objects, or to translate asynchonous events into a synchronous API. That the Web and video thereon "work" is proof of that. You can run the whole Internet over DNS, if you want to. It would not work as well as the one we have today. :) )

> but not with the implementation but rather the "abstract API" as Joe called it: the interface to the app as defined in the RFCs (for where it really *is* defined).
> 
> I think that this discussion with Joe maybe suffered from focusing on TCP. SCTP is perhaps a better starting point because it supports almost everything.

We can certainly do SCTP next, which should make the exercise look less arbitrary. (FWIW I don't think we can *eliminate* arbitrary decisions in classification and where to cut the line between components, or to determine which components are worth talking about. But minimizing them is a good goal. :) )

> So I'm thinking that a different (and, to me, perhaps more appropriate and more systematic) method to get a list of features could be to start with the read / write options in RFC 6458, extend it with all such options from the other protocols, and then, protocol by protocol, ask: "what does this protocol provide that the list now doesn't contain?". Not sure the overhead of this approach would be super large?  But I agree, you may end up with the same list the way you do it now.

Again, that captures knobs and indicators, less so interaction patterns. (I will say I'm not 100% convinced the interaction patterns are important to capture for the individual protocols, but paying attention to them will be *crucial* to making sure that TAPS-the-system sees uptake among application and platform developers)

Cheers,

Brian

---

From: Erik Nygren <[email-masked]>
Date: Wed, 17 Jun 2015 11:42:28 -0400

Another major item to add to the list would be:

- MTU/MSS negotiation and management, including initial negotiation,
response to packet-too-big signals from middle-boxes, and optional probing.

To what degree is it worth talking about known design limitations and
issues associated with each?  For example, checksums in TCP not being large
enough to detect errors in many high-volume real-world scenarios?
Erik

On Jun 11, 2015 7:53 AM, "Mirja Kühlewind" <[email-masked]>
wrote:

> Hi all,
>
> we gave it a first try to rewrite the component section for TCP. The
> insight I took from the discussion on the list is that components probably
> are much more linked to the implementation (choices) a certain protocol
> made while features are probably more high-level having the question in
> mind what does an application potentially want/need to know.
>
> (NAPT), TCP ports are
> places a lower bound on
> option is not supported.
> congestion window;
> We are currently still working on the list of features that results from
> thiese components but we are not there yet. Probably we not only need the
> features itself but also properties/aspects (or however you want to call
> this) of the feature. We already had this discussion a bit but wanted to
> postpone the decision if we really need to define an own term for this
> until we are sure that we need it.
>
> We are posting this list of (TCP) components now because we would like to
> get some feedback if this goes into the right direction/is on the right
> level of detail before we go on and apply this also to other protocols.
>
> Brian and Mirja
>
>
>

---

From: Joe Touch <[email-masked]>
Date: Wed, 17 Jun 2015 11:10:35 -0700

On 6/17/2015 1:44 AM, Michael Welzl wrote:
> I think that this discussion with Joe maybe suffered from focusing on
> TCP. 

To be fair, TCP has a simpler abstract API.

> SCTP is perhaps a better starting point because it supports
> almost everything. 

IMO, that makes it very hard as a starting point, and I also think that
TCP's variant of an API description is much better as an example.

E.g., Section 10 of RFC4960 claims it defines an abstract API
(ULP-to_SCTP), but it begins by describing a call to initialize a data
structure (INITIALIZE). That's decidedly NOT an abstract API; it's a
generic description of an implementation issue.

IMO, if we don't understand the difference between the API in RFC793 vs.
that in RFC4960 (and why 793 is a better example), then this is going to
be a very bumpy road.

Joe

---

From: Aaron Falk <[email-masked]>
Date: Wed, 17 Jun 2015 14:33:11 -0400

Some suggested homework for the group: if you haven't done so recently,
read section 3.8 of RFC793.  (It's only 8 pages.)

--aaron

---

From: Mirja Kühlewind <[email-masked]>
Date: Thu, 18 Jun 2015 10:48:12 +0200

Hi Joe,

I believe the approach Michael is proposing is to look at existing APIs as a starting point; not only abstract APIs. The assumption is that someone who implemented/designed an API, thought that it would be worth to provide a configuration possibility to the higher layer. This assumption is more true for SCTP than for TCP because there are quite a few different TCP implementation that are grown over time. Quite often a new interface was only created because a new feature was added to TCP; and to be on the safe side we allow the user to turn it off again.

That’s the reason why I prefer the approach we are/I'm taking right now (analyzing components). I think we should still describe the abstract API of RFC793 (and we do) as well as the SCTP API of RFC4960 in this document, but I personally would not and will not spend too much time analyzing other API. However, everybody who has time and is interested in this can of course provide his/her outcome as input for this document and we will happily take it and compare it to what we have so far.

Mirja

> Am 17.06.2015 um 20:10 schrieb Joe Touch <[email-masked]>:
> 
> 
>

---

From: Michael Welzl <[email-masked]>
Date: Thu, 18 Jun 2015 15:43:44 +0200

> On 18 Jun 2015, at 10:48, Mirja Kühlewind <[email-masked]> wrote:
> 
> Hi Joe,
> 
> I believe the approach Michael is proposing is to look at existing APIs as a starting point; not only abstract APIs.

No, wrong. Only abstract ones from RFCs, I said this before. These things would typically have preceding IETF debate, whereas trying to cover implementations is a huge and probably meaningless endeavour (the bar may be high for adding function calls to an API on system X and low for an API on system Y).

> The assumption is that someone who implemented/designed an API, thought that it would be worth to provide a configuration possibility to the higher layer. This assumption is more true for SCTP than for TCP because there are quite a few different TCP implementation that are grown over time. Quite often a new interface was only created because a new feature was added to TCP; and to be on the safe side we allow the user to turn it off again.
> 

But you misunderstood me. I was talking about RFCs (btw 6458, not 4960), not implementations out there.

More below, answering Joe  (hm, that rhymes ;-)  ) -

>> that in RFC4960 (and why 793 is a better example), then this is going to

How abstract it is in the RFC indeed isn't my main concern here: it's to start with the interface (however abstract it is) offered to applications as described in the RFCs, as this reflects what the designers (with some level of IETF consensus) thought should be exposed.
Now, of course SCTP has more options and is more complex in its usage than TCP, but it covers a larger part of the space of services in protocols - so I thought it's a good starting point, as in: 80% done by looking at 1 protocol, check the others for the remaining 20%. Something like that.

This is just me being pragmatic and trying to have a more systematic approach to developing a list of services. I agree with Brian that some level of arbitrariness will always be there, but we must try to minimize it I think.

Cheers,
Michael

---

From: Michael Welzl <[email-masked]>
Date: Thu, 18 Jun 2015 15:54:21 +0200

> On 17 Jun 2015, at 12:13, Brian Trammell <[email-masked]> wrote:
> 
> hi Michael, all,
> 

I expect that too, but I still don't understand the point of the component list above. I mean, yes, you may be able to map and say "we need components X Y Z to provide features A and B" but how does this help TAPS?

> ... understanding that interface definitions aren't just about which knobs (and indicators) the API provides, but also the interaction patterns it enables, and that these interaction patterns can a…

Yes, I agree, and I hope that this won't really bite us... or what's your plan for addressing this problem?

> Again, that captures knobs and indicators, less so interaction patterns. (I will say I'm not 100% convinced the interaction patterns are important to capture for the individual protocols, but payin…

I agree about that, but components won't capture these interaction patterns either, or (why/how) would they?

Cheers,
Michael

---

From: Mirja Kühlewind <[email-masked]>
Date: Thu, 18 Jun 2015 15:56:09 +0200

Hi Michael,

> Am 18.06.2015 um 15:43 schrieb Michael Welzl <[email-masked]>:
> 
> 

Okay, but then I don’t really understand your approach fully. Yes we should document and look at what’s already specified in RFC, however isn’t the goal of taps to actually figure out how to change/extend/improve these APIs? How can we figure out what’s missing/wrong if we only look at what’s already there?

Mirja

---

From: Michael Welzl <[email-masked]>
Date: Thu, 18 Jun 2015 18:44:53 +0200

> On 18. jun. 2015, at 15.56, Mirja Kühlewind <[email-masked]> wrote:
> 
> Hi Michael,
> 

*My* goal is, and has always been, to provide a simpler, general API that is protocol independent. Note that this is not only for simplicity for ease of use BUT also for the sake of being able to automatize. After all the major goal is to remove the strict binding between applications and a specific protocol choice.

To be able to do this (documents 2 and 3), we first need a list of the existing services - our toolbox, if you wish (document 1). Figuring out what's missing / wrong about today's APIs (except that they are bound to a specific protocol) has never been *my* major intention, and I certainly don't see that as the goal of this document. I'd be surprised if that's what the charter suggests?! But of course my opinion is only what it is, the charter reflects the consensus...

All this being said, it can be a nice side-effect of the document (and note that noone knows what a TAPS system will really look like, and how these RFCs will actually end up being used). So I'm not strongly opposing the approach you're now following in that I don't see a big issue with there being a list of components - I just think it's not particularly useful for the goal of the document and doesn't really help the group progress towards its goals. I thought that proposing something more systematic with less arbitrariness could make it easier to put everyone in the same boat (in a way: "look, the boat HAS to be like that, there wasn't much choice, sit down please" rather than "sorry I painted it green, I like that color; I can understand you would have preferred a blue boat...").

Cheers,
Michael

---

From: Joe Touch <[email-masked]>
Date: Thu, 18 Jun 2015 15:51:24 -0700

+1

On 6/18/2015 9:44 AM, Michael Welzl wrote:
> *My*  goal is, and has always been, to provide a simpler, general API
> that is protocol independent. Note that this is not only for
> simplicity for ease of use BUT also for the sake of being able to
> automatize. After all the major goal is to remove the strict binding
> between applications and a specific protocol choice.
>
> To be able to do this (documents 2 and 3), we first need a list of
> the existing services - our toolbox, if you wish (document 1).
> Figuring out what's missing / wrong about today's APIs (except that
> they are bound to a specific protocol) has never been*my*  major
> intention, and I certainly don't see that as the goal of this
> document. I'd be surprised if that's what the charter suggests?! But
> of course my opinion is only what it is, the charter reflects the
> consensus...

---

From: Brian Trammell <[email-masked]>
Date: Fri, 19 Jun 2015 12:07:19 +0200

hi Michael,

A few replies inline.

> On 18 Jun 2015, at 15:54, Michael Welzl <[email-masked]> wrote:
> 
> 

So as I see it, "features" are the TAPS view of the world of the future -- the set of things that transport protocols can do, and that a better interface can give you access to. "Components" are the view of the world of the present -- what the current definitions *and deployed implementations* of transport protocols can do, and what each of those features imply.

There are a few ways you can implement the TAPS API. The one we chose to pursue in the WG (or at least I thought we had) is that the TAPS API takes (1) information from the application about its requirements in terms of features and parameters on those features (if available), (2) information from the path about which transport protocols and options are usable on the path, and the selects a transport protocol, and acts as glue between the API and the underlying protocol.

In this approach, it is IMO important to catalog the protocol components (and the interactions among them) since the mappings between components and features might not be clean. This might not be the document to do that in. But we wanted to do the exercise to see what the outcome looked like.

<snip>

> Yes, I agree, and I hope that this won't really bite us... or what's your plan for addressing this problem?

In this document, I don't think we need to do anything. If we take an API-centric view, we simply need to note the interaction pattern supported by each API. In the services and interfaces documents, I think we need to explicitly address which interaction patterns we want to support.

> I agree about that, but components won't capture these interaction patterns either, or (why/how) would they?

No, they won't -- I was responding to two separate points here, sorry...

Cheers,

Brian

---

From: Michael Welzl <[email-masked]>
Date: Fri, 19 Jun 2015 13:18:34 +0200

> On 19 Jun 2015, at 12:07, Brian Trammell <[email-masked]> wrote:
> 
> hi Michael,
> 
> A few replies inline.
> 

I see. Well I don't have a problem with that, I was just suggesting that this is probably not the path of easy agreement.

> In this document, I don't think we need to do anything. If we take an API-centric view, we simply need to note the interaction pattern supported by each API. In the services and interfaces document…

That makes sense to me.

Cheers,
Michael

---

From: Mirja Kühlewind <[email-masked]>
Date: Fri, 19 Jun 2015 14:03:37 +0200

Hi Michael,

> *My* goal is, and has always been, to provide a simpler, general API that is protocol independent. Note that this is not only for simplicity for ease of use BUT also for the sake of being able to a…

Yes, I agree! (not sure if this is simpler though… depends on the definition of simple… but hopefully easier to use and understand for the overlying application).

> 
> To be able to do this (documents 2 and 3), we first need a list of the existing services - our toolbox, if you wish (document 1). Figuring out what's missing / wrong about today's APIs (except that they are bound to a specific protocol) has never been *my* major intention, and I certainly don't see that as the goal of this document. I'd be surprised if that's what the charter suggests?! But of course my opinion is only what it is, the charter reflects the consensus…

So there current API is always bound to a specify protocol which already provides you a certain set of service feature. At least in TCP there is not much choice left and there the current API does not give us a good indication which services are actually provided by TCP. Therefore from my point of view the only way to identify these services is to look at the protocol itself and not only the API. In SCTP it’s different and we definitely have to and will discuss the existing API in the document.

> 
> All this being said, it can be a nice side-effect of the document (and note that noone knows what a TAPS system will really look like, and how these RFCs will actually end up being used). So I'm not strongly opposing the approach you're now following in that I don't see a big issue with there being a list of components - I just think it's not particularly useful for the goal of the document and doesn't really help the group progress towards its goals. I thought that proposing something more systematic with less arbitrariness could make it easier to put everyone in the same boat (in a way: "look, the boat HAS to be like that, there wasn't much choice, sit down please" rather than "sorry I painted it green, I like that color; I can understand you would have preferred a blue boat...“).

I totally understand this point. But at least for TCP I think it is not sufficient to look at the (abstract) API because in TCP there are not much choices and therefore the services TCP provides are not exposed over the API. I personally currently don’t see how another approach would bring us the the goal of identify existing services.

Again, if you have time to work on an alternative approach, please go ahead and provide input or even submit an own draft and I’m/we’re really open to discuss this and see what makes more sense. 

Mirja

---

From: Brian Trammell <[email-masked]>
Date: Fri, 19 Jun 2015 14:32:36 +0200

hi Michael,

continued, inline.

> On 18 Jun 2015, at 18:44, Michael Welzl <[email-masked]> wrote:
> 
> 
> *My* goal is, and has always been, to provide a simpler, general API that is protocol independent.

+1, though I would at this point say "better" as opposed to "simpler" and "general", with the caveat that i'm not yet sure what better looks like. This gets back to my point about interaction patterns in the previous message, though: if the simpler API provides only stream interaction, or packet sequence interaction, or if it only allows receivers to get data through asynchronous notifications, it will make it hard to support . So maybe we want a better common API for defining the *requirements* of an association, and better TX/RX *APIs* plural, one for each interaction pattern we want to support.

> Note that this is not only for simplicity for ease of use BUT also for the sake of being able to automatize. After all the major goal is to remove the strict binding between applications and a specific protocol choice.

We share this higher level goal in any case.

> To be able to do this (documents 2 and 3), we first need a list of the existing services - our toolbox, if you wish (document 1). Figuring out what's missing / wrong about today's APIs (except that…

I don't think that's in scope for this document, either. The component (and decomposition) work is aimed at figuring out what the available features are, and what (in a "TAPS as glue layer over existing transports" design) the implications of using protocol X for feature Y are. The API work is a bit of a non-sequitur (but also important to note...)

> All this being said, it can be a nice side-effect of the document (and note that noone knows what a TAPS system will really look like, and how these RFCs will actually end up being used).

In general, if there's any content in this document that is useful but doesn't fit but we still find useful, we can certainly put it something else.

> So I'm not strongly opposing the approach you're now following in that I don't see a big issue with there being a list of components - I just think it's not particularly useful for the goal of the document and doesn't really help the group progress towards its goals. I thought that proposing something more systematic with less arbitrariness could make it easier to put everyone in the same boat (in a way: "look, the boat HAS to be like that, there wasn't much choice, sit down please" rather than "sorry I painted it green, I like that color; I can understand you would have preferred a blue boat...").

I agree. Given, though, that the protocols we're looking at, that they weren't designed from components, it is really not clear to me how to systematically decompose existing protocols without making arbitrary choices as to where to make the cut. (and I wouldn't read too much into the approach we're following -- we're trying to incorporate the input we've taken from discussion on the list into the structure of the document, and as Mirja says, we're completely open to trying other approaches to do that).

We could take an opposite approach here: jump forward to section 4, define the features we think we want -- this we can do more systematically, because we're only limited by the intersection of the features we want and the features we think we can realistically deploy, as opposed to the history represented by the protocol components -- and then use the components as a check on the feasibility of those features.

Cheers,

Brian

---

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

> On 19 Jun 2015, at 14:03, Mirja Kühlewind <[email-masked]> wrote:
> 
> Hi Michael,
> 

Agree too, easier to use is what I meant

> So there current API is always bound to a specify protocol which already provides you a certain set of service feature. At least in TCP there is not much choice left and there the current API does…

Exactly that's why I thought starting with TCP's API (even when it's the abstract one) is not very helpful.
Joe, Aaron: what is it you were expecting us to take away from reading section 3.8 of RFC 793?
( I can see it highlighting the need to discuss communication patterns  (or decide for a specific one) in document #2, but not really contributing much to the list in document #1 ? )

> I totally understand this point. But at least for TCP I think it is not sufficient to look at the (abstract) API because in TCP there are not much choices and therefore the services TCP provides ar…

Agree about TCP

> Again, if you have time to work on an alternative approach, please go ahead and provide input or even submit an own draft and I’m/we’re really open to discuss this and see what makes more sense. 

Ok....  well, I agree that what I request is easier said than done  :-(     myself, I've been working on a first version of document #2 as I think this would help us understand if the set of "services" or whatever we call them in document #1 is useful for the group's purpose.

Michael

---

From: Michael Welzl <[email-masked]>
Date: Fri, 19 Jun 2015 15:41:02 +0200

> On 19 Jun 2015, at 14:32, Brian Trammell <[email-masked]> wrote:
> 
> hi Michael,
> 
> continued, inline.
> 

I agree.

> I agree. Given, though, that the protocols we're looking at, that they weren't designed from components, it is really not clear to me how to systematically decompose existing protocols without making arbitrary choices as to where to make the cut.

but why decompose?

> (and I wouldn't read too much into the approach we're following -- we're trying to incorporate the input we've taken from discussion on the list into the structure of the document, and as Mirja says, we're completely open to trying other approaches to do that).
> 

Interesting idea - it sounds good to me!

Cheers,
Michael

---

From: Mirja Kühlewind <[email-masked]>
Date: Fri, 19 Jun 2015 16:15:51 +0200

Hi Michael,

> Ok....  well, I agree that what I request is easier said than done  :-(     myself, I've been working on a first version of document #2 as I think this would help us understand if the set of "servi…

Cool! I think that the alternative approach Brian just proposed: Start with the feature we think/know we want to have and the compare them with what we have in the first document.

Mirja

---

From: Joe Touch <[email-masked]>
Date: Fri, 19 Jun 2015 09:07:56 -0700

On 6/19/2015 7:15 AM, Mirja Kühlewind wrote:
> Cool! I think that the alternative approach Brian just proposed:
> Start with the feature we think/know we want to have and the compare
> them with what we have in the first document.

-1

If you don't know what you already have, it's hard to figure out why
what you need isn't there.

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 19 Jun 2015 09:15:08 -0700

On 6/19/2015 6:22 AM, Michael Welzl wrote:
>> So there current API is always bound to a specify protocol which
>> already provides you a certain set of service feature. At least in
>> TCP there is not much choice left and there the current API does
>> not give us a good indication which services are actually provided
>> by TCP. Therefore from my point of view the only way to identify
>> these services is to look at the protocol itself and not only the
>> API. In SCTP it’s different and we definitely have to and will
>> discuss the existing API in the document.
>
> Exactly that's why I thought starting with TCP's API 
> (even when it's the abstract one) is not very helpful.
>

No. IMO, the current description of that API fails to indicate the
controls *already* available to TCP.

I don't agree that the TCP API doesn't indicate the service TCP provides
- it's just implicit. E.g.:

	OPEN call
		indicates TCP is connection oriented

	SEND/RECEIVE calls
		indicates TCP is an ordered byte stream,
		that the user-level byte boundaries are NOT
		related to message boundaries, etc.

Yes, there's some "reading between the lines" to do here.

> ( I can see it highlighting the need
> to discuss communication patterns (or decide for a specific one) in
> document #2, but not really contributing much to the list in document
> #1 ? )

I believe the opposite is true.

Joe

---

From: Mohamed Oulmahdi <[email-masked]>
Date: Fri, 19 Jun 2015 23:39:11 +0200

> Yes, there's some "reading between the lines" to do here.

Of course, no one use a protocol without knowing the service it offers.
When the application requests a TCP connection, it really request a
reliable and ordered connection oriented service. The protocols primitives
are used to each one to offer a part of this service. The difficulty occurs
when several protocols are available, with mainly a certain service
overlapping. In this case, exposing Transport services by the protocols
offering them is not convenient to applications developers because they
must be aware of the several protocols details that are not always evident
to some of them. The objective is so simply to change this service
exposition from a protocol-based to a service-based, allowing developers to
request services without knowing anything about the underlying protocols
offering these services.

---

From: Joe Touch <[email-masked]>
Date: Fri, 19 Jun 2015 15:11:11 -0700

On 6/19/2015 2:39 PM, Mohamed Oulmahdi wrote:
> reliable and ordered connection oriented service. The protocols
> primitives are used to each one to offer a part of this service.

My point is that the API primitives do define the service offered in 
this case. You can't use TCP without using OPEN; OPEN exists only 
because TCP is connection-oriented.

Similarly, SEND/RECEIVE are handled in-order and the byte order within 
each call is preserved - which indicates that this is a byte stream 
service. The lack of boundary marking within the SEND/RECEIVE calls - 
and the indication that SEND/RECEIVE block boundaries are not preserved 
- indicates that this is a byte stream service with no internal boundaries.

All of this can be gleaned from the API in section 3.8 of RFC 793.

 > The
> difficulty occurs when several protocols are available, with mainly a
> certain service overlapping.

You're getting far ahead of the conversation, IMO. This document needs 
to start by explaining the services we already have before jumping into 
a "service of services" model.

I don't disagree with the goal, but it's impractical to develop a 
meta-interface when the base interface has not been described.

Joe

---

From: Mohamed Oulmahdi <[email-masked]>
Date: Sat, 20 Jun 2015 00:42:52 +0200

On Sat, Jun 20, 2015 at 12:11 AM, Joe Touch <[email-masked]> wrote:

>
> You're getting far ahead of the conversation, IMO. This document needs to
> start by explaining the services we already have before jumping into a
> "service of services" model.
>

It is just to say that TCP already defines its services, and the goal is
not to give another definition of these services, but only to change the
way they are exposed to applications. So the services definition already
exists, but implicitly.

---

From: Joe Touch <[email-masked]>
Date: Fri, 19 Jun 2015 15:55:01 -0700

On 6/19/2015 3:42 PM, Mohamed Oulmahdi wrote:
>
>
> On Sat, Jun 20, 2015 at 12:11 AM, Joe Touch <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>     You're getting far ahead of the conversation, IMO. This document
>     needs to start by explaining the services we already have before
>     jumping into a "service of services" model.
>

It's explicit - see section 3.8 of RFC 793. The issue with that variant 
is that it captures the state of TCP in 1981; it has evolved quite a bit 
since then. Although we do have a 793-bis in the works, the update of 
that section hasn't been tackled yet.

Let's put it this way:

	- if the goal of TAPS is to unify existing APIs,
	then those APIs need to be summarized together in one place

	- if TAPS is indeed focused solely on an alternate API,
	then it should NOT try to 'restate' the existing TCP API
	in a TAPS doc

"Do, or do not; there is no try."
	- Yoda

Joe

---

From: Michael Welzl <[email-masked]>
Date: Sat, 20 Jun 2015 10:35:31 +0200

> On 20. jun. 2015, at 00.55, Joe Touch <[email-masked]> wrote:
> 
> 
> 
> It's explicit - see section 3.8 of RFC 793. The issue with that variant is that it captures the state of TCP in 1981; it has evolved quite a bit since then. Although we do have a 793-bis in the works, the update of that section hasn't been tackled yet.
> 
> Let's put it this way:
> 

TAPS is focused on an alternate API that it's based on existing transports. As a way of analyzing existing transports and creating a foundation for this API, document #1 is written. I think this discussion is about the approach taken to write document #1.

So now I wonder what you're complaining about, as you go on about TCP already defining its services implicitly in the API. I mean, yes it does, okay - and so?  You criticized the SCTP API for not being abstract enough - so clearly if we'd just copy+paste the API descriptions of the RFCs of the considered transports in a list, that would look pretty messy. You seem to want a "clean" approach, but you're not going to get that unless we focus on TCP alone  :-)

I've been proposing go through transport APIs and then analyze what we have, because this way, SCTP is already going to give us a long list of services.
You've been saying that we should start with TCP. Well okay, but the service list there is pretty narrow. Maybe the TCP API isn't properly described in the current draft, okay, I think we can take that criticism for what it is. Still, I don't know what you're really after - in the end, we're going to get a list that's pretty similar to what's there now, and that's what we want, right?

- unordered reliable delivery of messages
- delivery of messages with timed delivery
- reliable delivery of a data stream (naturally that's ordered)

.... and so on. Right? Or what else is it you want / expect? 

Cheers,
Michael

---

From: Jon Crowcroft <[email-masked]>
Date: Sat, 20 Jun 2015 10:51:02 +0100

i dont have any spare time to do it, but maybe someone could have a go at
analyzing all the different TCP offload techniques, which would give
another lens to view this through...

On Sat, Jun 20, 2015 at 9:35 AM, Michael Welzl <[email-masked]> wrote:

> since then. Although we do have a 793-bis in the works, the update of that
> section hasn't been tackled yet.
> >
> > Let's put it this way:
> >
> TAPS is focused on an alternate API that it's based on existing
> transports. As a way of analyzing existing transports and creating a
> foundation for this API, document #1 is written. I think this discussion is
> about the approach taken to write document #1.
>
> So now I wonder what you're complaining about, as you go on about TCP
> already defining its services implicitly in the API. I mean, yes it does,
> okay - and so?  You criticized the SCTP API for not being abstract enough -
> so clearly if we'd just copy+paste the API descriptions of the RFCs of the
> considered transports in a list, that would look pretty messy. You seem to
> want a "clean" approach, but you're not going to get that unless we focus
> on TCP alone  :-)
>
> I've been proposing go through transport APIs and then analyze what we
> have, because this way, SCTP is already going to give us a long list of
> services.
> You've been saying that we should start with TCP. Well okay, but the
> service list there is pretty narrow. Maybe the TCP API isn't properly
> described in the current draft, okay, I think we can take that criticism
> for what it is. Still, I don't know what you're really after - in the end,
> we're going to get a list that's pretty similar to what's there now, and
> that's what we want, right?
>

---

From: Joe Touch <[email-masked]>
Date: Sat, 20 Jun 2015 10:32:37 -0700

Michael,

...
> transports. As a way of analyzing existing transports and creating
> a foundation for this API, document #1 is written. I think this
> discussion is about the approach taken to write document #1.
>
> So now I wonder what you're complaining about,

I'm trying to get Mohamed (and perhaps others) on the same page as you 
and I.

Joe

---

From: Wesley Eddy <[email-masked]>
Date: Sat, 20 Jun 2015 22:37:12 -0400

> that section hasn't been tackled yet.

I'm not sure that it will be tackled, but we should discuss that on the
TCPM list :).  Since there are no newer RFCs that alter, deprecate, or
replace that API, I don't think we have a good basis to change it in
793bis.

It's still pretty reasonable in my opinion.

-- 
Wes Eddy
MTI Systems