Re: [rtcweb] STUN for keep-alive

"Dan Wing" <dwing@cisco.com> Fri, 16 September 2011 18:02 UTC

Return-Path: <dwing@cisco.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0831C21F8B79 for <rtcweb@ietfa.amsl.com>; Fri, 16 Sep 2011 11:02:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.181
X-Spam-Level:
X-Spam-Status: No, score=-103.181 tagged_above=-999 required=5 tests=[AWL=-0.582, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJfx-fY-aAYN for <rtcweb@ietfa.amsl.com>; Fri, 16 Sep 2011 11:02:44 -0700 (PDT)
Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 32A9421F85F2 for <rtcweb@ietf.org>; Fri, 16 Sep 2011 11:02:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=3792; q=dns/txt; s=iport; t=1316196299; x=1317405899; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=dJPkD6Sb1IgsBudcy0h9y9642uEGfZTeU21EZ0Zngi0=; b=di8aYcuO2dHzeOXGotgDSDLgxDXl7v0Jr/idTTM2qz9jJv3R+MVq14Dm yqhojE5rPZGm+ttbaC2vUoQdMp1aCpYeYa/IGOvmoZRCkuiFRE+do5vt2 0z0jHDNyEkpWu+uLhpIOK1E91BFvq1areltaXp3MYPhK3Aq5HMJ9YnBJL Q=;
X-IronPort-AV: E=Sophos;i="4.68,394,1312156800"; d="scan'208";a="2604920"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 16 Sep 2011 18:04:59 +0000
Received: from dwingWS ([10.32.240.194]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p8GI4xBm020417; Fri, 16 Sep 2011 18:04:59 GMT
From: "Dan Wing" <dwing@cisco.com>
To: "'Muthu Arul Mozhi Perumal \(mperumal\)'" <mperumal@cisco.com>, "'Christer Holmberg'" <christer.holmberg@ericsson.com>, <rtcweb@ietf.org>
References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CB0@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB264@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CEB@XMB-BGL-414.cisco.com>
In-Reply-To: <1D062974A4845E4D8A343C653804920206648CEB@XMB-BGL-414.cisco.com>
Date: Fri, 16 Sep 2011 11:04:59 -0700
Message-ID: <092301cc749b$26223270$72669750$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acxyw30r82gF7xzoSe2t1rt6OG8s+wAA6iNwAABiKWAAAWch4ABzMI7g
Content-Language: en-us
Subject: Re: [rtcweb] STUN for keep-alive
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Sep 2011 18:02:45 -0000

> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> Behalf Of Muthu Arul Mozhi Perumal (mperumal)
> Sent: Wednesday, September 14, 2011 4:24 AM
> To: Christer Holmberg; rtcweb@ietf.org
> Subject: Re: [rtcweb] STUN for keep-alive
> 
> |Well, it depends on the amount of outgoing media traffic,
> |but in cases where you only receive media you would still
> |need to send keep-alives.
> 
> If you are not sending anything the NAT binding in that direction will
> likely timeout. On the other hand, if you are operating in a controlled
> environment ICE already allows you to set the STUN keepalive duration
> to
> the longest duration possible in your environment, so it is already
> flexible.

PCP can allow the client to know and control the NAT's UDP timeout,
http://tools.ietf.org/html/draft-ietf-pcp-base-13#section-7.3.

-d

> However, it mandates STUN keepalives to be used when an agent is a full
> ICE implementation and is communicating with a peer that supports ICE
> (lite/full). Are you saying it should allow a different UDP keepalive
> method because it can possible have a lesser performance impact?
> 
> Muthu
> 
> |-----Original Message-----
> |From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
> |Sent: Wednesday, September 14, 2011 3:59 PM
> |To: Muthu Arul Mozhi Perumal (mperumal); rtcweb@ietf.org
> |Subject: RE: [rtcweb] STUN for keep-alive
> |
> |
> |Hi,
> |
> |>|Because, eventhough the keep-alives messages aren't authenticated,
> and
> |>|do not trigger responses, a gateway would still have to
> |>|process them, and since a gateway typically would serve a large
> number of browser
> |>|clients, that could have quite big performance impact (the number of
> |>|STUN keep-alives sent per session of course depend on how much other
> |>|media traffic there is, but still).
> |>
> |>STUN keepalives are required by ICE only in the absence of
> |>media traffic.
> |
> |Yes. That's what I meant with the:
> |
> |	"(the number of STUN keep-alives sent per session of course
> depend on how much other media
> |traffic there is, but still)"
> |
> |...statement :)
> |
> |>Here are the snip from RFC 5245:
> |>
> |><snip>
> |>10.  Keepalives
> |>
> |>If there has been no packet sent on the candidate pair ICE is
> |>using for a media component for Tr seconds (where packets
> |>include those defined for the component (RTP or RTCP) and
> |>previous keepalives), an agent MUST generate a keepalive on
> |>that pair.  Tr SHOULD be configurable and SHOULD have a
> |>default of 15 seconds.  Tr MUST NOT be configured to less
> |>than 15 seconds.
> |></snip>
> |>
> |><snip>
> |>20.2.3.  Keepalives
> |>
> |>STUN keepalives (in the form of STUN Binding Indications) are
> |>sent in the middle of a media session.  However, they are
> |>sent only in the absence of actual media traffic. In
> |>deployments that are not utilizing Voice Activity Detection
> |>(VAD), the keepalives are never used and there is no increase
> |>in bandwidth usage.  When VAD is being used, keepalives will
> |>be sent during silence periods.  This involves a single
> |>packet every 15-20 seconds, far less than the packet every
> |>20-30 ms that is sent when there is voice.  Therefore,
> |>keepalives don't have any real impact on capacity planning.
> |></snip>
> |>
> |>Do you think there is still a problem?
> |
> |Well, it depends on the amount of outgoing media traffic, but in cases
> where you only receive media
> |you would still need to send keep-alives.
> |
> |Regards,
> |
> |Christer
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb