Re: [MEDIACTRL] ISSUE 17 - Control Framework - Transaction-Timeout

Eric Burger <eburger@standardstrack.com> Fri, 24 September 2010 00:10 UTC

Return-Path: <eburger@standardstrack.com>
X-Original-To: mediactrl@core3.amsl.com
Delivered-To: mediactrl@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A1323A68F1 for <mediactrl@core3.amsl.com>; Thu, 23 Sep 2010 17:10:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.427
X-Spam-Level:
X-Spam-Status: No, score=-102.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Bqyi4dEyYnM for <mediactrl@core3.amsl.com>; Thu, 23 Sep 2010 17:10:34 -0700 (PDT)
Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [205.134.249.249]) by core3.amsl.com (Postfix) with ESMTP id D8AFD3A68C6 for <mediactrl@ietf.org>; Thu, 23 Sep 2010 17:10:31 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=standardstrack.com; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Message-Id:References:To:X-Mailer:X-Source:X-Source-Args:X-Source-Dir; b=v7TB8HYjLB4alqj38jHMFlVC4T9yLSiziPsIuLwjmzNPU2H5FLTNqiKTEAIgWCkxxbHKxGBAsFEAYJKoqhVg+00QyfoRgEWBUMsXWcLWFsGPsMmruBIZBD75ICdliK8W;
Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8] helo=[192.168.15.101]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from <eburger@standardstrack.com>) id 1Oyvqz-00048s-OC; Thu, 23 Sep 2010 17:09:29 -0700
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: multipart/signed; boundary=Apple-Mail-41--120015416; protocol="application/pkcs7-signature"; micalg=sha1
From: Eric Burger <eburger@standardstrack.com>
In-Reply-To: <4C596F59.6050805@ns-technologies.com>
Date: Thu, 23 Sep 2010 17:29:06 -0400
Message-Id: <FE675FEA-224A-4D66-8345-AAD5CD2688B9@standardstrack.com>
References: <4C596F59.6050805@ns-technologies.com>
To: Chris Boulton <chris@ns-technologies.com>
X-Mailer: Apple Mail (2.1081)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Source:
X-Source-Args:
X-Source-Dir:
Cc: draft-ietf-mediactrl-sip-control-framework@tools.ietf.org, Camarillo Gonzalo <gonzalo.camarillo@ericsson.com>, mediactrl@ietf.org
Subject: Re: [MEDIACTRL] ISSUE 17 - Control Framework - Transaction-Timeout
X-BeenThere: mediactrl@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Media Control WG Discussion List <mediactrl.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mediactrl>, <mailto:mediactrl-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mediactrl>
List-Post: <mailto:mediactrl@ietf.org>
List-Help: <mailto:mediactrl-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mediactrl>, <mailto:mediactrl-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Sep 2010 00:10:41 -0000

Works for me.

On Aug 4, 2010, at 9:47 AM, Chris Boulton wrote:

> As part of our IESG review the following has been identified:
> Discuss:
> > Transaction-Timeout: The maximum allowed time between a Control
> > Client or Server issuing a framework message and receiving a
> > corresponding response. The value for 'Transaction-Timeout' is 5
> > seconds.
> 
> ISSUE 17 - DISCUSS: As I understand it, Transaction-Timeout has two meanings. For
> clients, it's the *minimum* amount of time they need to wait for the
> server to respond. For the server, it's the amount of time after which
> they should let the client know that processing will take longer. The
> mechanism as described isn't very robust. First, 5 seconds is not
> sufficiently larger than some Internet RTTs, which may cause spurious
> transaction failures even under normal operating conditions. Second,
> clients and servers use the same value, which means that if there is
> any delay spike or congestion along the path, a spurious transaction
> failures will occur.
> 
> The Transaction-Timeout set to 5 seconds does not seem appropriate for the job.  Firstly we need to take realistic (internet)
> RTT time into consideration.  Proposal is that we assert a RTT time of 10 seconds for the mediactrl framework. Thoughts?
> 
> We also need to construct more robust timeout rules for client and server.  The proposal is that:
> 
> - client sets Transaction-Timeout to be 2*RTT on issuing a request.
> - server sets Transaction-Timeout to be 1*RTT on receiving a request.
> 
> Chris.
> 
> -- 
> Chris Boulton
> CTO & Co-founder
> NS-Technologies
> m: +44.7876.476681
> _______________________________________________
> MEDIACTRL mailing list
> MEDIACTRL@ietf.org
> https://www.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl