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:
>  
>>> So I gather that there is no need to have a standards change, since 
>>> you seem to say that RFC allows you to abort a connection which 
>>> everyone is aware of. But it is the same RFC that says you MUST 
>>> persist a connection indefinetly as long as you receive 
>> ACKS, so you 
>>> are now providing an external override for this MUST behaviour.
>> I think the relevant text is:
>>
>>          4.2.2.17  Probing Zero Windows: RFC-793 Section 3.7, page 42
>>
>>             Probing of zero (offered) windows MUST be supported.
>>
>>             A TCP MAY keep its offered receive window closed
>>             indefinitely.  As long as the receiving TCP continues to
>>             send acknowledgments in response to the probe 
>> segments, the
>>             sending TCP MUST allow the connection to stay open.
>>
>> TCP. Not the user. Users get to abort connections.
>>
>>         4.2.2.13  Closing a Connection: RFC-793 Section 3.5
>>
>>             A TCP connection may terminate in two ways: (1) the normal
>>             TCP close sequence using a FIN handshake, and (2) 
>> an "abort"
>>             in which one or more RST segments are sent and the
>>             connection state is immediately discarded.
>>
>> FWIW.
> 
> I know I have read the above text many times, but there is an
> inconsitency here. While it says that TCP MUST keep the persist
> connection open, in the other hand it also says users can abort the
> connection no matter what state it is in. 

There is no inconsistency.

TCP keeps things open until told to do otherwise by the application. The
point of the text is that it is not TCP's decision to close the
connection - that's precisely because the application can do so if needed.

TCP always does as instructed by the user - i.e., when an ABORT or CLOSE
is issued. The point of the text is that TCP doesn't make a decision to
close the connection itself, not that the user can't make that command.

> So implementations can chose
> to have some optimal schemes built inside TCP module on behalf of the
> applications ( it is just a matter of programming/implementation) and
> have an implicit timer inside TCP which kills the TCP connection when
> timer expires and can inform the application about the connection death.

That timer would need to have a default of "infinite" - i.e., it would
default to never going off - to be compliant with RFC1122. Only if the
application instructed it otherwise could it activate.

Putting the timer inside TCP does nothing useful at that point except
complicate TCP. The timer can be in the OS or in the application with
exactly the same effect.

> [All the above actions are compliant to the RFC since RFC doesn't talk
> about how to implement TCP and it just gives a guidance, the term
> user/application and TCP are just used to illustrate the concept.]

If the timer defaults to "infinite", then yes, it would be compliant
with RFC1122. That doesn't change current behavior, though.

Joe

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