Re: [tcpm] draft-ananth-tcpm-persist-00.txt as a WG document

[David Borman <[e-mail]>]

On Oct 3, 2008, at 2:37 PM, Murali Bashyam wrote:
>
> My intent was that even where TCP implementations have a scheme for   
> dropping connections in the event
> of resource exhaustion (such as the Linux one does), they have  
> excluded connections in this state.
> The point i am trying to convey is that the 1122 portion has  
> (mis)guided them in that direction.

If this is true, it should be clarified.  1122 does not in any way say  
that ABORT does not apply to connections in persist state (probing a  
zero window).

...
>> In light of that I think that the sentence about "TCP itself SHOULD
>> not[sic] take any action..." is more confusing than the 1122 section.
>> It seems to imply that TCP might react differently to an abort than
>> the single paragraph in 793, and I don't think that's the case.
>
> What's meant here is that it's okay for the connection to get  
> aborted in this state, whatever the mechanism for doing
> so maybe: TCP can abort the connection and inform the application,  
> similar to the retransmit/persist timeout mechanisms
> already in place, or the application can choose to abort the  
> connection based policy, or the OS can do so based
> on resource management criteria. We can re-word that sentence and  
> paragraph to reflect this.

Just to be clear: TCP DOES NOT ABORT THE CONNECTION!  The OS or the  
application can choose to ABORT the connection, but TCP does not make  
this decision.  TCP does have retransmit timers, and it is allowed to  
terminate unresponsive connections, but it does not abort connections  
just because they are in persist state for long periods of time.   
Until you are running out of resources there is no good reason to  
terminate connections in persist state, and when you are running out  
of resources, it is the OS that is deciding whether or not to ABORT  
any TCP connections.


>> Now, a strictly defined abort command seems to somewhat contradict my
>> earlier comments about allowing implementers some freedom.  This is a
>> spot where the standards body has required a specific tool to be
>> available to applications (and OSes and resource managers): there  
>> must
>> be a way to annihilate a TCP connection from outside without regard  
>> to
>> its state or anything else.  The standard is silent about how the
>> command is used; that's the flexibility here.
>
> The abort semantics as specified by 793 are clear, they are not  
> specific to a particular state, it's the opinion
> of the authors that 1122 excludes it from being applied in this state.

Yes, that is an opinion, but it is wrong.  In no way does 1122 say  
that connections in persist state cannot be ABORTed.  What 1122 does  
say is that a connection being in persist state for a long time is not  
sufficient reason *by itself* to terminate a TCP connection, i.e.,  
don't time it out like you would a connection to a non-responsive host.

			-David Borman


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