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

Chris Boulton <chris@ns-technologies.com> Wed, 04 August 2010 13:46 UTC

Return-Path: <chris@ns-technologies.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 3E1423A6B7E for <mediactrl@core3.amsl.com>; Wed, 4 Aug 2010 06:46:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.165
X-Spam-Level:
X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 yRWhA3GkIsWC for <mediactrl@core3.amsl.com>; Wed, 4 Aug 2010 06:46:46 -0700 (PDT)
Received: from host.qbytedns.net (host.qbytedns.net [89.16.176.173]) by core3.amsl.com (Postfix) with ESMTP id 792173A6B33 for <mediactrl@ietf.org>; Wed, 4 Aug 2010 06:46:46 -0700 (PDT)
Received: from [195.171.3.120] (port=50733 helo=[192.168.2.5]) by host.qbytedns.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <chris@ns-technologies.com>) id 1OgeJN-0005qg-R2; Wed, 04 Aug 2010 14:47:14 +0100
Message-ID: <4C596F59.6050805@ns-technologies.com>
Date: Wed, 04 Aug 2010 14:47:05 +0100
From: Chris Boulton <chris@ns-technologies.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6
MIME-Version: 1.0
To: mediactrl@ietf.org
Content-Type: multipart/alternative; boundary="------------040403020001090107000203"
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - host.qbytedns.net
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - ns-technologies.com
X-Source:
X-Source-Args:
X-Source-Dir:
Cc: draft-ietf-mediactrl-sip-control-framework@tools.ietf.org, mediactrl-chairs@tools.ietf.org, gonzalo.camarillo@ericsson.com
Subject: [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: Wed, 04 Aug 2010 13:46:48 -0000

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 <http://www.ns-technologies.com>
m: +44.7876.476681