Re: [tcpm] TCP zero window timeout?

Ted Faber <faber@ISI.EDU> Tue, 29 August 2006 16:58 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1GI6vD-0004Ob-Kl; Tue, 29 Aug 2006 12:58:43 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1GI6vB-0004ON-OU for; Tue, 29 Aug 2006 12:58:41 -0400
Received: from ([]) by with esmtp (Exim 4.43) id 1GI6v9-0001qW-CQ for; Tue, 29 Aug 2006 12:58:41 -0400
Received: from ( []) by (8.13.8/8.13.6) with ESMTP id k7TGvuY6024451 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 29 Aug 2006 09:57:56 -0700 (PDT)
Received: (from faber@localhost) by (8.13.8/8.13.8/Submit) id k7TGvupq091256; Tue, 29 Aug 2006 09:57:56 -0700 (PDT) (envelope-from faber)
Date: Tue, 29 Aug 2006 09:57:56 -0700
From: Ted Faber <faber@ISI.EDU>
Subject: Re: [tcpm] TCP zero window timeout?
Message-ID: <>
References: <> <>
Mime-Version: 1.0
In-Reply-To: <>
User-Agent: Mutt/
X-ISI-4-43-8-MailScanner: Found to be clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
Cc: "Mahdavi, Jamshid" <>,, "Anantha Ramaiah (ananth)" <>, Fernando Gont <>
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: multipart/mixed; boundary="===============1224607630=="

On Mon, Aug 28, 2006 at 03:59:43PM -0700, MURALI BASHYAM wrote:
> --- Ted Faber <faber@ISI.EDU> wrote:
> > Why get TCP involved here?
> Because TCP's requirement to persist indefinitely
> creates the problem and only TCP is aware of how long
> the peer has been doing zero window offering.

TCP is completely unaware of how long a client has been offering a 0
receive window.  You'd have to change it to keep count of that.  That's
what you're proposing, correct?  

As an aside, RFC1122 says pretty unambiguously that both holding a zero
window and probing it regularly are intentionally supported.

> This does not take into account the fact that
> connections are persisting and probing for peer's zero
> window which is fundamental to the discussion.

The resource your proxy is running out of is CPU to do window probes???
If so, that's very surprising.  If not, can you tell me what your
concern is?

Looking at RFC1122 Section, it's hard to imagine a less CPU-
intensive way to deal with window probing than the exponential backoff
algorithm suggested there.

> A TCP sender which is simply trying to probe the peer
> for an indefinitely long amount of time certainly
> stops helping the application or the system once
> beyond some amount of time threshold. The threshold
> may be different for different  applications but for a
> given application and a system the threshold surely
> exists.  

Without getting too philosophical, the designers of TCP did explicitly
support connections that lock out transmission via a zero window size.

Ted Faber           PGP:
Unexpected attachment on this mail? See
tcpm mailing list