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

[David Borman <[e-mail]>]

On Nov 28, 2007, at 7:32 PM, MURALI BASHYAM wrote:
...
> The second aspect is the ability of the application to explicitly  
> cause the TCP connection
> to leave the ZWP state at the specified time independent of  
> available resources. There are
> applications where having this level of control over the TCP  
> connection makes sense (web, game servers).
> But aborting this connection with trigger from TCP or OS or  
> application is a protocol violation, i don't buy the fact
> that if the OS does it, it's not a violation, that's what i was  
> referring to as pure wordplay.

Fine.  Call it wordplay.  There's nothing wrong with that, because you  
*have* to get the words right.  You have to be crisp on the protocol  
definition.  The implementation can blur the boundaries, but the  
protocol definition can't.   The aborting of a connection (whether in  
persist or any other state) when the other side is alive and  
responding has to be done by the application.  TCP should not be doing  
that without direct instructions from the application.  Whether that  
is done directly by the application by using the existing abort or  
user timeout interface, or whether a new interface is defined to allow  
the application tells the OS to run a timer and abort the connection  
when the timer goes off, it is still being done under the direction of  
the application.


> A protocol is a contract between the sender and receiver here, and  
> the contract defines the wire
> behaviour.

The TCP protocol is what is defined in RFC 793/1122, and any other  
RFCs that are applicable.  It is more than just the wire behavior.


> I care about the wire behaviour of the
> connection, and if i observe the behaviour of the connection in the  
> ZWP state prior to this change, i see
> ACKs and probes exchanged infinitely. With this change (no matter  
> who does it, OS, app, TCP), i see
> ACKs and probes being exchanged for some time, followed by a RST  
> segment to abort the connection.
>
> Do you agree that if we do the latter without changing the wording  
> of RFC1122, it's a protocol
> violation?
> My claim all along has been that it is.

There already exists two mechanisms for the application to abort a  
connection, directly with the abort interface, or indirectly with the  
user timeout on the send interface, and you will get the same wire  
behavior, a connection in persist state gets aborted.

The only protocol problem here is to have TCP abort a connection in  
ZWP state without the application having first explicitly asked for  
that to happen.  And if you need a new interface to provide that  
functionality, then that will be a change to the TCP protocol.

The OS freeing up resources when they run out by doing things like  
aborting connections is not a protocol violation, because it isn't TCP  
making that decision.  Take that to the extreme, and you'd be arguing  
that the system crashing is a TCP protocol violation, and that's just  
silly.

>
>
> If we agree that it's a violation, then it's a standards track  
> nature of draft.

If it changes TCP, in this case adding a new User/TCP interface, then  
it should be on the standards track.

			-David Borman



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