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

[David Borman <[e-mail]>]

On Nov 27, 2007, at 5:51 PM, MURALI BASHYAM wrote:

>> 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.
>
> Since you going down this path, what's wrong with TCP doing it by  
> itself having
> received go-ahead from the application and/or the administrator of  
> the system?
> Seems as if we are going to extreme lengths and playing with system  
> boundary
> definitions here to avoid making a change where it hurts most (TCP).

Ok.

Don't confuse the protocol design with the implementation.  To  
paraphrase David Clark from many years ago: Strict protocol layering  
is a great way to design a protocol, but a terrible way to implement  
it.  In the RFCs, we are dealing with the protocol design, not the  
implementation, so we need crisp boundaries, and clarity on which side  
of the boundary things are on.  The implementation is free to do as  
much blurring between the boundaries as it wants, as long as what goes  
on the wire is still correct.

RFC 793 and 1122 talk about how to process a *single* TCP stream.   
They do not discuss interaction between TCP multiple streams (because  
from a protocol design standpoint, there shouldn't be any).  When we  
get into the area of resource starvation, we are now talking about how  
multiple TCP streams interact between each other through the use of  
common resources.  Dealing with that is not part of the design of TCP.

If the user timeout on the SEND call is not sufficient for the  
application when dealing with a connection, then we would need a  
proposal to add a new timer to TCP, with a clear description of how  
the application sets the timer, when TCP should clear/restart the  
timer, and what to do when the timer goes off.  That has nothing to do  
resource starvation.  If the timeout on the SEND call would be  
sufficient for the application, but the TCP implementation does not  
provide the ability to set a timer on the SEND call, then that is an  
implementation issue.

If you want to have a higher-level view that goes through and aborts  
connections in persist state when resources are low, perhaps based on  
how long they've been in persist state, that is not part of the TCP  
design.  It might be *implemented* right in the middle of the TCP  
code, but it is not part of the TCP protocol design.

			-David Borman



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