Re: [BEHAVE] duration between 2 rtp-keepalive

"Dan Wing" <dwing@cisco.com> Thu, 01 July 2010 18:49 UTC

Return-Path: <dwing@cisco.com>
X-Original-To: behave@core3.amsl.com
Delivered-To: behave@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 894723A69A3 for <behave@core3.amsl.com>; Thu, 1 Jul 2010 11:49:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.734
X-Spam-Level:
X-Spam-Status: No, score=-8.734 tagged_above=-999 required=5 tests=[AWL=-0.549, BAYES_40=-0.185, RCVD_IN_DNSWL_HI=-8]
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 IyZ2MVq0GXmC for <behave@core3.amsl.com>; Thu, 1 Jul 2010 11:49:19 -0700 (PDT)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 722BE3A67A3 for <behave@ietf.org>; Thu, 1 Jul 2010 11:49:19 -0700 (PDT)
Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAAWALEyrR7H+/2dsb2JhbACURIsmcaUbmiyFJQSDcQ
X-IronPort-AV: E=Sophos;i="4.53,521,1272844800"; d="scan'208";a="220500169"
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 01 Jul 2010 18:49:31 +0000
Received: from dwingWS (sjc-vpn6-476.cisco.com [10.21.121.220]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o61InUrh023903; Thu, 1 Jul 2010 18:49:31 GMT
From: Dan Wing <dwing@cisco.com>
To: 'Xavier Marjou' <xavier.marjou@gmail.com>, behave@ietf.org
References: <AANLkTik76yVPdAB6ZTV-30wqcNb4UFW8v-9JK_bwWdmZ@mail.gmail.com>
In-Reply-To: <AANLkTik76yVPdAB6ZTV-30wqcNb4UFW8v-9JK_bwWdmZ@mail.gmail.com>
Date: Thu, 01 Jul 2010 11:49:30 -0700
Message-ID: <136c01cb194e$23ea9230$6bbfb690$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Content-Language: en-us
Thread-Index: AcsZMXBljpJgMouISvegd7lKc/ipFAAGvgTw
Subject: Re: [BEHAVE] duration between 2 rtp-keepalive
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Jul 2010 18:49:20 -0000

> -----Original Message-----
> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On
> Behalf Of Xavier Marjou
> Sent: Thursday, July 01, 2010 8:24 AM
> To: behave@ietf.org WG
> Subject: [BEHAVE] duration between 2 rtp-keepalive
> 
> Hi,
> 
> In the context of the RTP keepalive draft (AVT's WG draft), there is
> the need  to specify the duration between two keepalives for each
> transport protocol (cf Section 7 of
> http://tools.ietf.org/html/draft-ietf-avt-app-rtp-keepalive-08).
> 
> Thus my question is what would be the value for: TCP, DCCP, SCTP?

For TCP, RFC5382 says:

   REQ-5:  If a NAT cannot determine whether the endpoints of a TCP
      connection are active, it MAY abandon the session if it has been
      idle for some time.  In such cases, the value of the "established
      connection idle-timeout" MUST NOT be less than 2 hours 4 minutes.
      The value of the "transitory connection idle-timeout" MUST NOT be
      less than 4 minutes.
      a) The value of the NAT idle-timeouts MAY be configurable.

https://fit.nokia.com/lars/tmp/2010-hgw-study.pdf shows the results
of a study including TCP timeouts.  However, that is not cross-
referenced with how often those NATs occur in the field (market share).  
About TCP timeouts, it says:

	"TCP-1: Figure 7 shows the measured TCP binding timeouts.
Because the measured timeouts are highly variable,
the plot uses a log scale to make the differences more visible.
Values for NATs which had not timed out by 24 hours
are not shown.
	be1 has the shortest timeout; it consistently times out TCP
bindings after 239 sec - less than 4 min. More than half of
the devices fail to meet the IETF recommended timeout of
124 min [9]. Some of the NATs appear to retain a TCP bindings
for considerably longer - the seven devices on the right
in Figure 7 still had not timed out their bindings after 24 h,
which was the cutoff for this test."


I am not aware of commercially-available NATs that support DCCP
or SCTP.

-d