Re: [tcpm] TCP zero window timeout?

Fernando Gont <fernando@gont.com.ar> Tue, 29 August 2006 00:19 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHrKX-0005Bk-9h; Mon, 28 Aug 2006 20:19:49 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHrKV-0005BL-SO for tcpm@ietf.org; Mon, 28 Aug 2006 20:19:47 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHpSt-00051D-Pc for tcpm@ietf.org; Mon, 28 Aug 2006 18:20:19 -0400
Received: from smtp1.xmundo.net ([201.216.232.80]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GHonS-0002JP-UD for tcpm@ietf.org; Mon, 28 Aug 2006 17:37:32 -0400
Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id AECF3F0D237; Mon, 28 Aug 2006 18:38:02 -0300 (ART)
Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k7SLbFev011925; Mon, 28 Aug 2006 18:37:19 -0300
Message-Id: <7.0.1.0.0.20060828174015.05ff6df8@gont.com.ar>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0
Date: Mon, 28 Aug 2006 17:43:29 -0300
To: "Kuthonuzo Luruo (STSD)" <kuthonuzo.luruo@hp.com>, MURALI BASHYAM <murali_bashyam@yahoo.com>
From: Fernando Gont <fernando@gont.com.ar>
Subject: Re: [tcpm] TCP zero window timeout?
In-Reply-To: <1156768336.4600.3.camel@knuth.india.hp.com>
References: <20060826230546.41460.qmail@web31713.mail.mud.yahoo.com> <1156768336.4600.3.camel@knuth.india.hp.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: -1.9 (-)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Cc: tcpm@ietf.org
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Errors-To: tcpm-bounces@ietf.org

At 09:32 28/08/2006, Kuthonuzo Luruo (STSD) wrote:

>Several OSes do include a socket option SO_SNDTIMEO, that can be set by
>an application to specify the amount of time a transmit function blocks
>when flow control prevents the transmission of data.

This is not exactly true.

IIRC, SND_SNDTIMEO is a timeout on the relevant socket call (send(), 
write(), etc.), and not on actual data delivery to the remote TCP endpoint.

As long as there's is enough free space in the socket send buffer, 
write()/send() won't block, and therefore the SO_SNDTIMEO timeout won;t apply.

(Yes, if the TCP sender is sending bulk data, at some point the send 
buffer will most lilely fill up, and this timeout will kick in....)

Kindest regards,

--
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1






_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm