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

[David Borman <[e-mail]>]

Ok, I haven't chimed in yet on this conversation.

While I agree with the document on the identification of the problem,  
I disagree with the proposed solution (changing TCP to time out  
connections in persist state).  Having a connection stay in persist  
state for long periods of time (i.e., zero window probes continue to  
be ACKed) by itself is not a bad thing.  That is how TCP was designed  
to work.  Connections can survive through lots of adversity.  If a  
connection is stuck because it is waiting for user action and the user  
walked away and went home for the day, he should be able to come back  
the next morning and do what needs to be done, and then the connection  
will continue.

As has already been stated, the issue is what should the OS do when it  
runs out of resources.  TCP implementations typically oversubscribe  
their resources, and run into problems when all the open connections  
try to use up all the resources that they've been told they can use.   
In this situation, the OS has to figure out some way to free up  
resources.  There may be some things it can do without killing  
connections (e.g., flush TCP resequencing queues), but usually that  
won't be sufficient if you have a runaway or malicious source that is  
causing the resource problem in the first place.  In this situation,  
anything the OS decides to do, including killing TCP connections, is  
at the discretion of the OS, and I don't that view as violating any  
RFC.  You're out of resources, you have to do something.  This is not  
a TCP protocol issue, it is an OS implementation issue.

Now, it might be that connections that have been in persist state for  
a long period of time are good candidates for the OS to abort to free  
up resources.  But doing that has to be a decision of the OS or the  
application, not of TCP.  TCP can keep track of how long connections  
are in persist state, so that if the OS or application asks, it can  
judiciously choose which ones are the best to abort.

Let's look at keep-alives.  They are not part of the TCP  
specification.  They aren't perfect.  In RFC 1122, we acknowledged  
their existence, and placed restrictions on them.  The must default to  
off.  The default interval for sending keep-alives must be at least 2  
hours.  You don't drop a connection due to just one missed keep- 
alive.  "A TCP keep-alive mechanism should only be invoked in server  
applications that might otherwise hang indefinitely and consume  
resources unnecessarily if a client crashes or aborts a connection  
during a network failure."  But they do serve a useful purpose.

In the end, it is the responsibility of the application to place  
limits on its TCP connections.  If the OS provides a simple way for  
the application to say "ABORT this TCP connection if it remains in  
persist state (or idle state, or...) for more than X period of time",  
I don't have any objection to that.  That's an agreement between the  
application and the OS.  It has the nice advantage that the OS knows  
what to do with the connection after the application has written all  
its data and closed its side of the connection, and hence is no longer  
able to ABORT the connection.  When the system runs out of resources,  
it is the responsibility of the OS to decide how to deal with that  
situation.  If TCP is consuming large amounts of resources, then the  
OS will have to have some way to tell TCP how to free up resources,  
including ABORTing connections.

There have always been ways that TCP implementation can tie up  
resources, and we've been working to mitigate those things all along.   
(The first one I remember dealing with was the "send each octet in a  
separate packet, but don't send the first octet".  That tied up  
resources on BSD on the TCP resequencing queue.) One difference  
between now and 15-20 years ago, is that back then many of the  
resource issues were not intentional, but due to poorly written  
applications or just new scenarios that hadn't been exercised before.   
But what hasn't changed is that the problems are usually due to  
implementation issues, not problems with the TCP protocol.  And that  
holds true in this case.

			-David Borman


On Nov 26, 2007, at 1:38 PM, Mark Allman wrote:

...
>
>> Like I said: you and I are not going to agree about how to interpret
> RFC112 (in 2007).  It would be good to hear other opinions.
>
> allman



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