Re: Summary of responses so far and proposal moving forward[WasRe:[tcpm] Is this a problem?]

MURALI BASHYAM <murali_bashyam@yahoo.com> Sun, 02 December 2007 16:47 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 1Iyrye-0003Gv-Bi; Sun, 02 Dec 2007 11:47:32 -0500
Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Iyryd-0003Gn-Oq for tcpm-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 11:47:31 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iyryd-0003Gb-FN for tcpm@ietf.org; Sun, 02 Dec 2007 11:47:31 -0500
Received: from web31704.mail.mud.yahoo.com ([68.142.201.184]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Iyryd-00080T-1g for tcpm@ietf.org; Sun, 02 Dec 2007 11:47:31 -0500
Received: (qmail 83270 invoked by uid 60001); 2 Dec 2007 16:47:30 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=Sj0KHWYPG75EhL5UPbUuaenpX0aDjZfsqr7qA5yi9KpsNjwZGSvGgF1bWeQmhuT9nMyv1lymklhc57iEAQ7jsC9ba8nGq8zZF3WS29f8MJvo+A6+22eRBm8agdcqcljtaE+Hvc/qgBldKVzstC7mlCmNMNJFGyvt543ZqQwLfQY=;
X-YMail-OSG: MpppZBcVM1nTpbaPDzpqm07xoR_ZwgYtYbgwdITn_X4AuOiYXPPcLvl8fIbKWXkVUm2yR9bMbqvB2uHMtJt.lM5Ky8COcmbR5JPrsBCFgq3.3LTuADg-
Received: from [67.161.9.166] by web31704.mail.mud.yahoo.com via HTTP; Sun, 02 Dec 2007 08:47:30 PST
X-Mailer: YahooMailRC/818.27 YahooMailWebService/0.7.157
Date: Sun, 02 Dec 2007 08:47:30 -0800
From: MURALI BASHYAM <murali_bashyam@yahoo.com>
Subject: Re: Summary of responses so far and proposal moving forward[WasRe:[tcpm] Is this a problem?]
To: Joe Touch <touch@ISI.EDU>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-ID: <442337.83267.qm@web31704.mail.mud.yahoo.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8
Cc: Anantha Ramaiah <ananth@cisco.com>, TCP Maintenance and Minor Extensions WG <tcpm@ietf.org>, David Borman <david.borman@windriver.com>
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


----- Original Message ----
> From: Joe Touch <touch@ISI.EDU>
> To: MURALI BASHYAM <murali_bashyam@yahoo.com>
> Cc: David Borman <david.borman@windriver.com>; Anantha Ramaiah <ananth@cisco.com>; TCP Maintenance and Minor Extensions WG <tcpm@ietf.org>
> Sent: Friday, November 30, 2007 10:31:50 PM
> Subject: Re: Summary of responses so far and proposal moving forward[WasRe:[tcpm] Is this a problem?]
> 
> 
> 
> MURALI BASHYAM wrote:
> ...
> > The issue here is that TCP cannot inform the application and have
> the
> 
 
> > application initiate the abort, because it is  not necessary that
> the
> 
 application has that connection state 
> > around anymore, it could have been destroyed already, i've alluded
> to
> 
  this issue before. 
> 
> And I have already shown how to address it - SO_LINGER.
> 
> In the case of a Unix close() call, this can be used to cause
> close()
> 
 to
>  block until either the graceful shutdown completes (i.e., all data is
> sent and ack'd, and the other end closes) OR a timer expires.
> 
> SO_LINGER already supports a timer for this purpose.
> 
> Can we please stop trying to add to TCP that which ***ALREADY*** exists
> in the implementation?

Turning SO_LINGER on causes the application to pay a penalty in the normal
scenario, where the close call will block even with a legitimate receiver (or a slow
network). This is precisely why applications do not use it, it ties up resources 
unnecessarily, and how about applications that want non-blocking semantics?. High
performance applications care about non-blocking semantics.

Let's stop recommending to applications how to use the 
socket layer, we have to approach this in a manner that doesn't question or change
their socket layer usage model. Application changes should be incremental and not
disruptive, that's the idea of doing this in the transport layer in the first place.



> 
> Joe
> 
> 




      ____________________________________________________________________________________
Be a better pen pal. 
Text or chat with friends inside Yahoo! Mail. See how.  http://overview.mail.yahoo.com/


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