Re: Summary of responses so far and proposal moving forward [Was Re: [tcpm] Is this a problem?]

[Joe Touch <[e-mail]>]

Anantha Ramaiah (ananth) wrote:
>  
>>> Not sure what you mean above. RFC Compliance applies to 
>> protocol, not 
>>> to API.
>> Please see RFC793. It specifies an API. Although the IETF 
>> avoided APIs for a while, my understanding is that they are 
>> again considered relevant standards work.
> 
> I don't think so. The API's specified by 793 needs to treated as
> illustrational purposes only, they are not supposed to be interpreted as
> standards. 

Please review RFC793. It does talk about the fact that considerable
flexibility is afforded to the implementer, but also expects the basic
functions described there.

. Like you noted above : "It specifies an API" not "the API".
> Now RFC 793 doesn't talk about sockets, 

Sockets are implementation-specific.

> it doesn't talk about SO_LINGER
> and SO_KEEPALIVE for example, does it mean that any stack which
> implements API's not mentioned by RFC 793, isn't compliant? Nope.  

1122 talks about keepalives; how they're implemented is up to the coder.
Some of the functions of so_linger are an artifact of blocking OS calls;
it is expected that apps can call ABORT at any time, and so if calls
block, there needs to be a mechanism to get around it.

> Again for example Keepalive option is very common in all TCP stacks, now
> RFC doesn't mention about TCP keepalives, 
> does it make a particular TCP stack which implements Keepalive
> non-compliant, if so all TCP stacks out there (BSD, Linux etc.,) would
> become non-compliant :-)

See 1122.

> So, the point in short is if I have an socket API, which tells TCP,
> abort this connection after a stipulated time in persist state, the TCP
> implementation can start a timer (a new timer OR overload an unused
> timer) the moment the connection enters persist state, and can tear down
> the connection after the timer expiry. This action would be treated as
> compliant to 1122 as would the OS running a timer in it's own context
> and killing the TCP connection. The key point is that resulting action
> is the same no matter which method you chose to exercise a particular
> protocol action.

That is true. However, just like we don't require everyone to implement
so_linger, we would not accept a requirement for that timer option to TCP.

>>> API is a local thing. One implementation can use sockets, whereas 
>>> other can using something totally different, what matters 
>> is what is 
>>> sent on the wire and the response which is received.
>> A protocol is defined by:
>>
>> 	- formats of packets sent on the wire
>> 	- state at the endpoints
>> 	- events that cause state transitions, packet emissions,
>> 	  and signals to the application, triggered by:
>> 		- packets arriving
>> 		- upper layer commands (i.e., "application" events)
>> 		- time
> 
> True but protocol (TCP) is one thing, upper (application) and lower
> layer (IP) interfaces is another. The protocol compliance is measured by
> "if I send something, what do you I get in response" "If I send
> something in state X, is the behaviour as defined by the standard?".
> Upper layer and lower interface are simply local and they tend to evolve
> and that is benefit of a generic design of a particular protocol layer.

Upper and lower layers to given protocol define its semantics and the
semantics it expects from the lower layer. While implementations evolve,
the requirements - the minimums required for correct interoperation -
don't unless they are accompanied by changes to the specification.

>> RFC793 is a good example of this set.
>>
>> The upper layer commmands and signals to the upper layer 
>> constitute the API, and it is as much a part of the protocol 
>> as packets on the wire.
>> Although there are a variety of ways to implement a SEND, 
>> RECEIVE, OPEN, CLOSE, STATUS, or ABORT, all TCP 
>> implementations must include them in their API, and they and 
>> their basic arguments are specified in RFC793.
> 
> Right, but these are the basic API's. The API's tend to expand and
> evolve and as long as their evolution doesn't "disturb" the standard,
> then we are golden.

If you want to extend your implementation's API, that's fine, but not an
RFC. If you want to extend the basic minimum required API, that would
require a change to the protocol - as other changes (e.g., keepalives,
nagle, ecn, etc.) have over the years.

Joe

_______________________________________________
tcpm mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tcpm