Re: [rtcweb] STUN for keep-alive

"Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com> Wed, 14 September 2011 10:23 UTC

Return-Path: <mperumal@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 CA6BF21F8C4E for <rtcweb@ietfa.amsl.com>; Wed, 14 Sep 2011 03:23:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.435
X-Spam-Level:
X-Spam-Status: No, score=-10.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 VDkmV5CSRTYh for <rtcweb@ietfa.amsl.com>; Wed, 14 Sep 2011 03:23:10 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id C715121F8C47 for <rtcweb@ietf.org>; Wed, 14 Sep 2011 03:23:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=3168; q=dns/txt; s=iport; t=1315995919; x=1317205519; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=+C4R/CDBvLgK/hoyu4B86OzJZpFRJNbdmBLBik6de38=; b=KM17zTtEoaBUcG1eVQFwEax40Pp5+no+r+idFB/VmwXo3P7aojT8JTBz NwTFcGh2kqJj0ukvOuBR2icxWfK0uNBJ/W3W2rKL2VX2Vr/+XRBdj4a0D 9DFINU/gDnwROl2STcwhQzTRAs6xtbI1atE/5fx0Pj4b8eImbJiYQvMx7 Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqcAAFiAcE5Io8US/2dsb2JhbABBmGuPD3iBUwEBBQEBAQ8BHQo0FwQCAQgRBAEBCwYXAQYBJh8JCAEBBAEKCAgah1mXQAGeL4YOYASHbJB3jAk
X-IronPort-AV: E=Sophos;i="4.68,379,1312156800"; d="scan'208";a="115373281"
Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-1.cisco.com with ESMTP; 14 Sep 2011 10:25:16 +0000
Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p8EAPGWw024602; Wed, 14 Sep 2011 10:25:16 GMT
Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Sep 2011 15:55:16 +0530
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 14 Sep 2011 15:55:13 +0530
Message-ID: <1D062974A4845E4D8A343C653804920206648CB0@XMB-BGL-414.cisco.com>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [rtcweb] STUN for keep-alive
Thread-Index: Acxyw30r82gF7xzoSe2t1rt6OG8s+wAA6iNw
References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se>
From: "Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>, rtcweb@ietf.org
X-OriginalArrivalTime: 14 Sep 2011 10:25:16.0137 (UTC) FILETIME=[9850F590:01CC72C8]
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: Wed, 14 Sep 2011 10:23:10 -0000

Christer,

|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. 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?

Muthu

|-----Original Message-----
|From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
Behalf Of Christer Holmberg
|Sent: Wednesday, September 14, 2011 3:19 PM
|To: rtcweb@ietf.org
|Subject: [rtcweb] STUN for keep-alive
|
|
|Hi,
|
|Assuming we would use ICE for media authorization, it has been
indicated that, for legacy
|interoperability, a gateway would be required in many cases (as the
legacy entities might not support
|ICE).
|
|ICE "bundles" functions together, meaning that if you use STUN for
media authorization purpose (which
|is a part of the connectivity check purpose), you will also use STUN
for keep-alive purpose (for UDP
|based media).
|
|My question is: would we be able to relax the requirement to use STUN
for keep-alive? 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).
|
|So, for RTP based media, one could use RTP, and for UDP based data
channels "dummy" UDP packets
|(unless there is a protocol on top of UDP which provides a keep-alive
mechanism itself).
|
|Regards,
|
|Christer
|
|_______________________________________________
|rtcweb mailing list
|rtcweb@ietf.org
|https://www.ietf.org/mailman/listinfo/rtcweb