Re: [tcpm] Is this a problem?

MURALI BASHYAM <murali_bashyam@yahoo.com> Tue, 06 November 2007 18:37 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 1IpTIo-0004CX-Qz; Tue, 06 Nov 2007 13:37:30 -0500
Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IpTIo-0004CS-0D for tcpm-confirm+ok@megatron.ietf.org; Tue, 06 Nov 2007 13:37:30 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpTIn-0004CK-Mu for tcpm@ietf.org; Tue, 06 Nov 2007 13:37:29 -0500
Received: from web31702.mail.mud.yahoo.com ([68.142.201.182]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IpTIk-0003od-0S for tcpm@ietf.org; Tue, 06 Nov 2007 13:37:29 -0500
Received: (qmail 10538 invoked by uid 60001); 6 Nov 2007 18:37:25 -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=G+CU4nHIfeWGSbMomO6VV2Ljt69FyNOPp/PE8hkPIidndZvs+8pT9dhbGW8IJOyJdHv5Dvpw1rCoqIY33QavUCi7Dr/iQQbLEvS9SILsRr7OVGudolT5al2RUfZJvz+5EjkRfxg3LZw6pORA6FQAN2KCQQt2DynZvoEReox95ic=;
X-YMail-OSG: On0oakwVM1kGzDoFGzAoClqi0s2wgq9c7MEA4EzDB2cyVdZnLvwPKnM10Vlq2s81_MdQwwHnTZx9qEXC0RZgjXbbuPS3p2cL6BrRbz5IGqA5Vqd5_o0-
Received: from [69.3.29.18] by web31702.mail.mud.yahoo.com via HTTP; Tue, 06 Nov 2007 10:37:24 PST
X-Mailer: YahooMailRC/814.05 YahooMailWebService/0.7.152
Date: Tue, 06 Nov 2007 10:37:24 -0800
From: MURALI BASHYAM <murali_bashyam@yahoo.com>
Subject: Re: [tcpm] Is this a problem?
To: Joe Touch <touch@ISI.EDU>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-ID: <121882.10140.qm@web31702.mail.mud.yahoo.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Cc: tcpm@ietf.org, Lloyd Wood <L.Wood@surrey.ac.uk>
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

We want to limit the timer to the sender's persist state only, any other timeout overloads the semantics of the application,
and may also cause unnecessary timeouts for the application. In fact there are instances where the application may not
even have the connection state around to implement the timout correctly, like the tail of a long HTTP response. After sending the tail of the 
response, the application can close the connection and release its connection memory, during this window only TCP has the 
connection state. We've done a lot of testing and design  for handling all these cases, and to implement this correctly, 
we need TCP's involvement.

Murali

----- Original Message ----
From: Joe Touch <touch@ISI.EDU>
To: MURALI BASHYAM <murali_bashyam@yahoo.com>
Cc: Lloyd Wood <L.Wood@surrey.ac.uk>; tcpm@ietf.org
Sent: Tuesday, November 6, 2007 10:24:49 AM
Subject: Re: [tcpm] Is this a problem?




MURALI BASHYAM wrote:
> In the spirit of keeping changes to TCP protocol minimal, how about
> having the application specify a time limit via the socket API when
 TCP gets into this
>  state and TCP cuts its indefinite wait down to this timeout? 

Why not set the timer in the application and ABORT or CLOSE the
connection when the timer goes off?

Joe





__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


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