Re: [tcpinc] TCP's treatment of data in SYN packets

[Joe Touch <[e-mail]>]

On 8/8/2016 11:21 AM, David Mazieres wrote:
> Joe Touch <[e-mail]> writes:
>
>>> * Many of the uses concern APIs that implementations SHOULD provide.
>>>   The reason for the SHOULD is that in some cases this may be impossible
>>>   or inapplicable.  For example, if you are implementing TCP-ENO inside
>>>   a dedicated NAS server, there might not be the same notion of
>>>   applications giving API commands.  On the other hand, these points are
>>>   pretty important to the success of TCP-ENO, and should be followed in
>>>   the vast majority of cases.
>> The problem with SHOULD for APIs is that users then can't rely on any of
>> those features. So the real question is:
>>     - what are the API features that are absolutely required
>>     - why are you listing any that are optional?
>>
>> For APIs, the second set ought to be optimizations, not features or
>> capabilities IMO.
> Because the very notion of an API is optional in some cases. 

The point of the API is to indicate how the layer above TCP interacts
with TCP.

>  An
> embedded single-purpose network device might not be implemented in terms
> of sockets or anything else, but rather might have the device
> functionality completely intermingled with the protocol implementation.

That is an implementation issue. The API is an architectural one.

> Since TCP-ENO is above all a protocol, there's no reason to deem such
> implementations non-compliant.  

A protocol without an API is not a protocol anymore. A protocol is
*defined* by the API it creates (to the upper layers), the API it
expects (from the lower layers; for link protocols, this is the link
wiring), the messages it exchanges, the state it keeps, and the rules
that govern how these 2 APIs, messages, and state interact.

> On the other hand, if this ships with
> the linux kernel and there's no API call to get the session ID out of
> the kernel, we have a problem.
You have a problem if you bundle it with an app and the app needs to get
at the session ID and has no way to do so as well.

That's the same problem - an incomplete implementation.

> If this occurred only once in the document, I could add a sentence about
> the requirement applying only when there's a narrow interface to TCP
> such as a socket system call interface.  Since there are multiple
> requirements about the API, it would get tedious to repeat such a
> sentence.
An API is *instantiated* in a socket interface in Unix, but not in other
OSes.

Think of the API as only the calls that TCP imports/exports to any other
program that uses TCP as a transport.

Joe