RE: [tcpm] TCP zero window timeout?

MURALI BASHYAM <murali_bashyam@yahoo.com> Tue, 29 August 2006 19:01 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI8q1-0006Qq-PM; Tue, 29 Aug 2006 15:01:29 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI8q0-0006Pj-AE for tcpm@ietf.org; Tue, 29 Aug 2006 15:01:28 -0400
Received: from web31701.mail.mud.yahoo.com ([68.142.201.181]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GI8py-0006aJ-0I for tcpm@ietf.org; Tue, 29 Aug 2006 15:01:28 -0400
Received: (qmail 88553 invoked by uid 60001); 29 Aug 2006 18:54:44 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=rAw9GEaryZkZkaT2wc9kEgdrBmKEh374VwOwn+uSBiLr6myGG/vCkPSqYvp9LWD7LZ093gXTc+T1KaRiTOkhHTwswBRCkhEU0ufN3JSQjCKH+i/8coI6qdtqzZoclyt4p0t7eDsDGYN07/GJWY0fxRBS6p4AEQtUTw6joUYarb8= ;
Message-ID: <20060829185444.88551.qmail@web31701.mail.mud.yahoo.com>
Received: from [24.6.24.35] by web31701.mail.mud.yahoo.com via HTTP; Tue, 29 Aug 2006 11:54:44 PDT
Date: Tue, 29 Aug 2006 11:54:44 -0700 (PDT)
From: MURALI BASHYAM <murali_bashyam@yahoo.com>
Subject: RE: [tcpm] TCP zero window timeout?
To: Caitlin Bestler <caitlinb@broadcom.com>, Ted Faber <faber@ISI.EDU>
In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F189EDC5@NT-SJCA-0751.brcm.ad.broadcom.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8
Cc: "Mahdavi, Jamshid" <jamshid.mahdavi@bluecoat.com>, tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" <ananth@cisco.com>, Fernando Gont <fernando@gont.com.ar>
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


--- Caitlin Bestler <caitlinb@broadcom.com> wrote:

> MURALI BASHYAM wrote:
>  
> >> 
> > 
> > I think the crux of the issue here is that this is
> left to
> > the client side application control which means
> open game for hackers.
> > 
> > Murali
> 
> I think it is a given that a server application can
> terminate
> the connection to any client if the behaviour of
> that client
> means that the server no longer wishes to maintain
> the connection.
> 

The application is not aware of the client's behaviour
here and as far as he is concerned the data is out of
his control. 

> I am not aware of any RFC that would impair the
> ability of
> the server application to interact with the local
> TCP stack
> to achieve these results.

Are u suggesting that the application query TCP to
determine that the connection is stuck in persist
state and how much of the data has been sent or not
and so on? That sounds a little roundabout and
complicated...
> 
> Is there a specific RFC requirement that you believe
> impairs
> creation of local interfaces to achieve the results
> you desire?
> In general, if the application layer has the right
> to do something
> it has the right to delegate that authority to a
> lower layer on
> the local stack and doing so will contradict the
> wire protocol.

The application layer does not have enough information
to take the corrective actions here.

Murali
> 
> 
> 
> 


__________________________________________________
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