Re: [tcpm] TCP zero window timeout?

Fernando Gont <> Mon, 28 August 2006 21:37 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1GHonY-0003yM-4e; Mon, 28 Aug 2006 17:37:36 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1GHonW-0003xg-Fz for; Mon, 28 Aug 2006 17:37:34 -0400
Received: from ([]) by with esmtp (Exim 4.43) id 1GHonV-0002dC-2k for; Mon, 28 Aug 2006 17:37:34 -0400
Received: from ( []) by (Postfix) with ESMTP id 832F0F0D23A; Mon, 28 Aug 2006 18:38:06 -0300 (ART)
Received: from ( []) (authenticated bits=0) by (8.12.11/8.12.11) with ESMTP id k7SLbFex011925; Mon, 28 Aug 2006 18:37:22 -0300
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version
Date: Mon, 28 Aug 2006 17:50:48 -0300
To: MURALI BASHYAM <>, Mahesh Jethanandani <>, "Mahdavi, Jamshid" <>
From: Fernando Gont <>
Subject: Re: [tcpm] TCP zero window timeout?
In-Reply-To: <>
References: <> <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Score: 0.1 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Cc:, "Anantha Ramaiah (ananth)" <>
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: <>, <>

At 20:05 26/08/2006, MURALI BASHYAM wrote:

>Having said that, i'd say this timeout is in the same
>spirit as the upper bound on the retransmit mechanism
>of TCP. TCP could indefinitely retransmit and have the
>application timeout too, correct?

I disagree. In the case of the RTO, you don't have any hints of the 
TCP segments getting to the remote TCP endpoint. Hence, after some 
number of retransmission, you don;t have much else to do than to 
abort the connection.

In the case of zero window, as far as TCP is concerned, there's 
nothing wrong with an endpoint advertising a zero window. And you do 
know that packets are getting to the remote TCP endpoint (that's why 
you are getting the advertisements, after all).

>The problem is that
>TCP has a persist state which can potentially exist
>infinitely long  and which lends itself to abuse by a
>malicious peer.

This is the same thing as saying that there should be an "idle 
connection timeout", because a connection can be opened, and no data 
needs to be transmitted on the connection for the connection to be kept open.

That said, some upper limit on the number of window-probes might not 
hurt, but then you get into which value to use.
If too small, you may kill legitimate users. If too long, it may be useless.

And I doubt there really is something in between.

Kindest regards,

Fernando Gont
e-mail: ||
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

tcpm mailing list