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

[David Borman <[e-mail]>]

Anantha,

You're still hung up on the differentiation between the protocol  
design and the implementation.  You have to make a choice.  Something  
is either specified within the TCP protocol, and hence is on the  
standards track, or it is outside the scope of the TCP protocol and  
would only be an informational RFC; there may be things in both areas.  
But if you can't cleanly separate the protocol design from the  
implementation, then you will not be able to make progress in either  
area.

The issue is not about where the functionality is implemented, but how  
it is documented and whether or not it changes the design of the TCP  
protocol.  My guess is that the best you can hope for in modifying TCP  
is to add a User/TCP interface that allows the application to set a  
new timer to abort the connection if it remains too long in persist  
state (and you'll probably still have resistance).  The interface has  
to be clearly defined, as well as the semantics on when the timer gets  
started, restarted and disabled, and what happens when the timer goes  
off.  Think of it this way: what would you add to RFC 793?  A separate  
description would describe how an application/OS might make use of  
this, but that would be informational only.

			-David Borman

On Nov 29, 2007, at 9:21 PM, Anantha Ramaiah (ananth) wrote:

> Hi David,
>
> Firstly, I appreciate your explanations on TCP design and the
> differences between standard and implementation, those are all good.
>
> That said, it appears that this is what is being said (at least that  
> is
> what is being inferred in the email exchanges) :-
>
> Case 1:
> Abort by the application and OS
> ==================================
>
> "The application OR any entity (like OS) which is instructed by the
> application to abort the TCP connection when deemed necessary". "The  
> OS
> can abort the TCP connection when deemed necessary". These actions  
> seems
> to enjoy full compliance of RFC 793/1122.
>
> Also an example : if there are 270 connections hanging out in persist
> state for 110 days, the system administrator chooses to clear some of
> these connections, now system administrator is acting on behalf of the
> system and may not be the application, this is not a violation of the
> RFC, it appears.
>
> WHEREAS
>
> Case 2:
> Aborts done inside TCP layer
> ============================
>
> Assuming that one implementation chooses to have a design like :
> instructs each individual components in the system like transports  
> layer
> to abort some connections and thereby relinquish system resources when
> deemed necessary using an explicit or implicit feedback from the OS.  
> Now
> this action seems to be violating the RFC since it was done inside the
> jurisdiction of TCP code. I am having hard time understanding this. To
> me, it is pure implementation thingy.
>
> To me all the above actions (case 1 and 2), either are all compliant  
> to
> RFC OR all of them aren't. May be it is just me.
...



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