Re: [rtcweb] STUN for keep-alive

"Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com> Wed, 14 September 2011 12:06 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 4DF9921F8906 for <rtcweb@ietfa.amsl.com>; Wed, 14 Sep 2011 05:06:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.46
X-Spam-Level:
X-Spam-Status: No, score=-10.46 tagged_above=-999 required=5 tests=[AWL=0.139, 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 lGxvJ5OL3pq7 for <rtcweb@ietfa.amsl.com>; Wed, 14 Sep 2011 05:06:46 -0700 (PDT)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id E0DD621F8888 for <rtcweb@ietf.org>; Wed, 14 Sep 2011 05:06:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=4802; q=dns/txt; s=iport; t=1316002135; x=1317211735; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=rRygDkcyiQCe/G0Owhcz5WIt9MvmuS2ijN82VcddYNE=; b=HW9MtW9efMjxTAxkaGxEPrvuMSakn0GD7z1m+DJN3VrKZghKus4VbXWU //3W8taxI7grnaLRMiWpGZUIhuvOBEVQSMvVik3B3ACFv1oHqKOhZt3KQ ZBX/GR6eE90/V2YJCHhpXE8A93mPhJ8DiaB5Ns2GhGMHVT3anSGb3TR2T c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqcAABCYcE5Io8US/2dsb2JhbABBmGuPD3iBUwEBBRIBHQpLBAIBCBEEAQELBhcBBgFFCQgBAQQBCggIGp9iAZ4yhg5gBIdskHeMCQ
X-IronPort-AV: E=Sophos;i="4.68,380,1312156800"; d="scan'208";a="54545762"
Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-2.cisco.com with ESMTP; 14 Sep 2011 12:08:51 +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 p8EC8jFH012358; Wed, 14 Sep 2011 12:08:50 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 17:38:46 +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 17:38:45 +0530
Message-ID: <1D062974A4845E4D8A343C653804920206648D0F@XMB-BGL-414.cisco.com>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233EDB2F0@ESESSCMS0356.eemea.ericsson.se>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [rtcweb] STUN for keep-alive
Thread-Index: Acxyw30r82gF7xzoSe2t1rt6OG8s+wAA6iNwAABiKWAAAWch4AAAqu/QAABRLRA=
References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CB0@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB264@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CEB@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB2F0@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 12:08:46.0985 (UTC) FILETIME=[0E452790:01CC72D7]
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 12:06:47 -0000

|Sure, but there is still a max time between the keep-alives.

You are free to set it to a very long duration that disables keepalives
for all practical purposes (assuming such duration is represented by a
32-bit unsigned integer you can set it to ~136 years).

|Using e.g. RTP, the media handler would not have to be 
|prepared to receive the STUN keep-alives in the first place, 
|it could simply just relay whatever comes on the media plane.

If the media handles can handle STUN binding requests efficiently I
don't see why they can't handle STUN binding indications (keepalives) in
a similar manner. On the other hand, if the media handles aren't STUN
aware and are just relaying STUN binding requests in the media plane as
UDP/RTP, they would do the same also for STUN keepalives.

Muthu

|-----Original Message-----
|From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
|Sent: Wednesday, September 14, 2011 5:01 PM
|To: Muthu Arul Mozhi Perumal (mperumal); rtcweb@ietf.org
|Subject: RE: [rtcweb] STUN for keep-alive
|
|
|Hi,
|
|>>|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.
|
|Sure, but there is still a max time between the keep-alives.
|
|>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?
|
|Yes.
|
|Also, it's not only about how often the STUN keep-alives would be sent,
and the perfomance impact that
|would have. Using e.g. RTP, the media handler would not have to be
prepared to receive the STUN keep-
|alives in the first place, it could simply just relay whatever comes on
the media plane.
|
|Regards,
|
|Christer
|
|
|
|
|> |-----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
|>