From owner-tcp-impl@grc.nasa.gov  Mon Aug 25 08:33:13 2003
Received: from seraph3.grc.nasa.gov (seraph3.grc.nasa.gov [128.156.10.12])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13235
	for <tcpimpl-archive@lists.ietf.org>; Mon, 25 Aug 2003 08:33:13 -0400 (EDT)
Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33])
	by seraph3.grc.nasa.gov (Postfix) with ESMTP id 52ADC6BB02
	for <tcpimpl-archive@lists.ietf.org>; Mon, 25 Aug 2003 08:32:47 -0400 (EDT)
Received: (from listserv@localhost)
	by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.9) id h7PCDr9L020558
	for tcp-impl-outgoing; Mon, 25 Aug 2003 08:13:53 -0400 (EDT)
Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.grc.nasa.gov [139.88.112.21])
	by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.9) with ESMTP id h7PCDpld020546
	for <tcp-impl@grc.nasa.gov>; Mon, 25 Aug 2003 08:13:51 -0400 (EDT)
Received: from huahine.grc.nasa.gov (localhost [127.0.0.1])
	by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.9/8.12.9) with ESMTP id h7PCDnkF009360
	for <tcp-impl@grc.nasa.gov>; Mon, 25 Aug 2003 08:13:49 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by huahine.grc.nasa.gov (NASA GRC 8.12.9/8.12.9) with ESMTP id h7PCDniN003490
	for <tcp-impl@grc.nasa.gov>; Mon, 25 Aug 2003 08:13:49 -0400 (EDT)
Received: from huahine.grc.nasa.gov ([127.0.0.1])
 by localhost (huahine [127.0.0.1]) (amavisd-new, port 10024) with LMTP
 id 29372-26 for <tcp-impl@grc.nasa.gov>;
 Mon, 25 Aug 2003 08:13:48 -0400 (EDT)
Received: from seraph2.grc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33])
	by huahine.grc.nasa.gov (NASA GRC 8.12.9/8.12.9) with ESMTP id h7PCDgT7003476
	for <tcp-impl@grc.nasa.gov>; Mon, 25 Aug 2003 08:13:42 -0400 (EDT)
Received: from MAILBLR.engineering.netscaler.com (unknown [65.219.20.4])
	by seraph2.grc.nasa.gov (Postfix) with ESMTP id E592768A7D
	for <tcp-impl@grc.nasa.gov>; Mon, 25 Aug 2003 08:13:40 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
Subject: my-persist-probe
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Date: Mon, 25 Aug 2003 17:43:05 +0530
Message-ID: <22AE4241D2F5994A872ECC8C870DAF9908964C@MAILBLR.engineering.netscaler.com>
Thread-Topic: my-persist-probe
Thread-Index: AcNrAjy+GLyrrYDXSdK62neIBFlpNg==
From: "Prakash Khemani" <khemani@netscaler.com>
To: <tcp-impl@grc.nasa.gov>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by lombok-fi.lerc.nasa.gov id h7PCDpld020547
Sender: owner-tcp-impl@grc.nasa.gov
Precedence: bulk
Content-Transfer-Encoding: 8bit

Say to simplify my TCP stack implementation I want to modify the
persist-probe structure in the following way

My stack will generate a persist probe that will not carry one new byte
of data. Instead the persist probe will look more like the keep-alive
probe. My stack will generate a persist probe that will be a pure-ack
packet (packet w/o data) with sequence number equal to (SND.UNA - 1). I
am hoping that the stack that receives my-persist-probe will treat it as
a keep-alive probe and will always ACK it with the current window value.

I have tested my-persist-probe against Linux, FreeBSD 4.x, Solaris 2.8,
Win98, WinNT and Win 2000. All these systems treat my-persist-probe as
the keep-alive probe and properly ACK it with the current window.

So - is there a corner case where the receiving system might not ACK
my-persist-probe? Is this approach OK even though it violates the
standards? Why do the standards suggest that the persist probe should
carry one byte of data?

-- prakash