Re: [Taps] TCP components

[Joe Touch <[e-mail]>]

On 6/19/2015 6:22 AM, Michael Welzl wrote:
>
> On 19 Jun 2015, at 14:03, Mirja Kühlewind <[e-mail]> 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.
>
> Joe, Aaron: what is it you were expecting us to take away from 
> reading section 3.8 of RFC 793?

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