Re: [Taps] TCP components

[Michael Welzl <[e-mail]>]

> On 20. jun. 2015, at 00.55, Joe Touch <[e-mail]> wrote:
> 
> 
> 
> On 6/19/2015 3:42 PM, Mohamed Oulmahdi wrote:
>> 
>> 
>> On Sat, Jun 20, 2015 at 12:11 AM, Joe Touch <[e-mail]
>> <mailto:[e-mail]>> 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.
>> 
>>    I don't disagree with the goal, but it's impractical to develop a
>>    meta-interface when the base interface has not been described.
>> 
>> 
>> 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.
> 
> 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

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