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

Speaking only for myself.

On Wed, Nov 28, 2007 at 05:32:07PM -0800, 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.
> 
> A protocol is a contract between the sender and receiver here, and the
> contract defines the wire behaviour. 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.

If you believe that aborting a connection advertising a zero window is a
violation of the TCP specs, there's a lot of violation going on.  Any
time a process is killed or a machine goes down, TCP connections are
aborted (some advertising a zero window).  I find it hard to consider
all of those as non-conforming TCPs.

Now, looking at the text in front of us (RFC1122 in particular), one can
either believe that the TCP designers really intended for zero-window
connections to be maintained by any means possible, including starving
the host of memory and processing power, or that they intended what
David Borman described - to lay out the behavior of the protocol in the
absence of resource contention.  I prefer the latter; I'm sure the
designers considered the possibility of resource exhaustion and David's
interpretation allows plenty of room for operating systems and
applications to address it through calling ABORT on well-chosen
connections.

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG