Date: Thu, 29 Nov 2007 09:27:42 -0800
From: Ted Faber <faber@ISI.EDU>
To: MURALI BASHYAM <murali_bashyam@yahoo.com>
Subject: Re: Summary of responses so far and proposal moving forward[WasRe:
 [tcpm] Is this a problem?]
Message-ID: <20071129172742.GC15498@hut.isi.edu>
References: <389727.79747.qm@web31710.mail.mud.yahoo.com>
Mime-Version: 1.0
In-Reply-To: <389727.79747.qm@web31710.mail.mud.yahoo.com>
User-Agent: Mutt/1.4.2.3i
Cc: TCP Maintenance and Minor Extensions WG <tcpm@ietf.org>,
 David Borman <david.borman@windriver.com>,
 Mark Allman <mallman@icir.org>, Joe Touch <touch@ISI.EDU>
Precedence: list
Content-Type: multipart/mixed; boundary="===============0979006714=="
Errors-To: tcpm-bounces@ietf.org


--===============0979006714==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature"; boundary="O3RTKUHj+75w1tg5"
Content-Disposition: inline


--O3RTKUHj+75w1tg5
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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.
>=20
> 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.
>=20
> 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.

--=20
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

--O3RTKUHj+75w1tg5
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (FreeBSD)

iD8DBQFHTvaOaUz3f+Zf+XsRAswaAJ9qbC4sTRgFLE0p6LKVOoDou/po4wCeO9hr
ITGQdMwyVSMx3QFpQkI81uo=
=ePiB
-----END PGP SIGNATURE-----

--O3RTKUHj+75w1tg5--



--===============0979006714==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm

--===============0979006714==--