Re: [tcpm] Is this a problem?

Mahesh Jethanandani <mahesh@cisco.com> Tue, 06 November 2007 20:09 UTC

Return-path: <tcpm-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpUkC-0000kw-Nh; Tue, 06 Nov 2007 15:09:52 -0500
Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IpUkB-0000kr-V8 for tcpm-confirm+ok@megatron.ietf.org; Tue, 06 Nov 2007 15:09:51 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpUkB-0000kc-LT for tcpm@ietf.org; Tue, 06 Nov 2007 15:09:51 -0500
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpUk7-0006ER-NU for tcpm@ietf.org; Tue, 06 Nov 2007 15:09:51 -0500
X-IronPort-AV: E=Sophos;i="4.21,380,1188802800"; d="gif'147?scan'147,208,217,147";a="413875928"
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 06 Nov 2007 12:08:57 -0800
Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lA6K8uME022416; Tue, 6 Nov 2007 12:08:56 -0800
Received: from [171.69.75.40] (dhcp-171-69-75-40.cisco.com [171.69.75.40]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id lA6K8ueF018505; Tue, 6 Nov 2007 20:08:56 GMT
Message-ID: <4730C9D6.1020700@cisco.com>
Date: Tue, 06 Nov 2007 12:08:54 -0800
From: Mahesh Jethanandani <mahesh@cisco.com>
Organization: Cisco Systems Inc.
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: eblanton@cs.ohiou.edu, tcpm@ietf.org
Subject: Re: [tcpm] Is this a problem?
References: <121882.10140.qm@web31702.mail.mud.yahoo.com> <4730B50A.1030102@isi.edu> <20071106190845.GC5881@elb.elitists.net> <4730BC89.5000909@isi.edu> <20071106192746.GE5881@elb.elitists.net> <20071106193912.GF5881@elb.elitists.net>
In-Reply-To: <20071106193912.GF5881@elb.elitists.net>
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9596; t=1194379736; x=1195243736; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mahesh@cisco.com; z=From:=20Mahesh=20Jethanandani=20<mahesh@cisco.com> |Subject:=20Re=3A=20[tcpm]=20Is=20this=20a=20problem? |Sender:=20; bh=P8bRns+nW244QZF60HhtYFGn5iZuPOmVXYSDredbJb4=; b=gCFRgaMHaMZbyHDCj8noN5v8o28DAzREDNOVJGuQ0secvkBF+XNTcUk9FSpzd/qThDRo5FKD bQjt9fpQ2usPk5jJgGytWAHCiu52hwEA3Vmw1KfTGk2BuAwdqi9/svWMk1eHTRecpU6Ym/Yamp oO8vglnEDZHZ2qfxnm7Xpqxug=;
Authentication-Results: sj-dkim-1; header.From=mahesh@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; );
X-Spam-Score: -1.4 (-)
X-Scan-Signature: 453b1bfcf0292bffe4cab90ba115f503
Cc:
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>
Content-Type: multipart/mixed; boundary="===============0559495710=="
Errors-To: tcpm-bounces@ietf.org

Ethan,

Would we not receive a EWOULDBLOCK if the connection was throttled 
because of congestion in the network? Under the scenario you describe we 
would have timed out a connection that was either slow or congested. Is 
that true?

Ethan Blanton wrote:
> Ethan Blanton spake unto us the following wisdom:
>   
>> It is my understanding (correct me if I am wrong) that close() returns
>> immediately, regardless of queued data in the send buffer.  In
>> addition, I am not aware of any way to force a reset on a TCP socket
>> without pending data in the read buffer.
>>     
>
> SO_LINGER is indeed more flexible than I have used it for -- it can be
> used to solve both of these problems.  For the benefit of those
> listening:
>
> 1) Set SO_LINGER with l_onoff != 0 and l_linger = timeout in seconds.
> 2) If a nonblocking close returns EWOULDBLOCK, the linger timeout
>    expired, so:
>    2a) set SO_LINGER with l_onoff != 0 and l_linger = 0
>    2b) call close, which will emit a RST
>
> I recant my previous claims -- this can be handled cleanly with
> standard sockets.
>
>   
>>>> It does not seem unreasonable to add a zero-window timeout tunable to
>>>> any given TCP implementation; I don't necessarily think it is a TCP
>>>> standardization issue, however, as there is no wire impact.
>>>>         
>
> I do stand by this, however.
>
> Ethan
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www1.ietf.org/mailman/listinfo/tcpm
>   

-- 

*Mahesh Jethanandani*
*Technical Leader*
**Corporate Development*
*
mahesh@cisco.com <mailto:mahesh@cisco.com>
Phone :*+1 408 527-8230*
Fax :*+1 408 527-6351*

	

**
170 West Tasman Drive
San Jose, CA 95070
United States
www.cisco.com <http://www.cisco.com>

	 

This e-mail may contain confidential and privileged material for the 
sole use of the intended recipient. Any review, use, distribution or 
disclosure by others is strictly prohibited. If you are not the intended 
recipient (or authorized to receive for the recipient), please contact 
the sender by reply e-mail and delete all copies of this message.


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