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 |>
- [rtcweb] STUN for keep-alive Christer Holmberg
- Re: [rtcweb] STUN for keep-alive Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] STUN for keep-alive Christer Holmberg
- Re: [rtcweb] STUN for keep-alive Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] STUN for keep-alive Christer Holmberg
- Re: [rtcweb] STUN for keep-alive Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] STUN for keep-alive Christer Holmberg
- Re: [rtcweb] STUN for keep-alive Jonathan Lennox
- Re: [rtcweb] STUN for keep-alive Randell Jesup
- Re: [rtcweb] STUN for keep-alive sisalem
- Re: [rtcweb] STUN for keep-alive Magnus Westerlund
- Re: [rtcweb] STUN for keep-alive Harald Alvestrand
- Re: [rtcweb] STUN for keep-alive Eric Rescorla
- Re: [rtcweb] STUN for keep-alive Christer Holmberg
- Re: [rtcweb] STUN for keep-alive Göran Eriksson AP
- Re: [rtcweb] STUN for keep-alive Eric Rescorla
- Re: [rtcweb] STUN for keep-alive Dan Wing
- Re: [rtcweb] STUN for keep-alive Dan Wing
- Re: [rtcweb] STUN for keep-alive Dzonatas Sol
- Re: [rtcweb] STUN for keep-alive Eric Rescorla
- Re: [rtcweb] STUN for keep-alive Dan Wing
- Re: [rtcweb] STUN for keep-alive Dzonatas Sol
- Re: [rtcweb] STUN for keep-alive Harald Alvestrand
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Olle E. Johansson
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Hadriel Kaplan
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Olle E. Johansson
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Hadriel Kaplan
- Re: [rtcweb] STUN for keep-alive Magnus Westerlund
- [rtcweb] consent freshness [was RE: STUN for keep… Dan Wing
- Re: [rtcweb] consent freshness [was RE: STUN for … Magnus Westerlund
- Re: [rtcweb] consent freshness [was RE: STUN for … Dan Wing
- Re: [rtcweb] consent freshness [was RE: STUN for … Eric Rescorla
- Re: [rtcweb] consent freshness [was RE: STUN for … Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] STUN for keep-alive Randell Jesup
- Re: [rtcweb] consent freshness [was RE: STUN for … Magnus Westerlund
- Re: [rtcweb] STUN for keep-alive Magnus Westerlund
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Iñaki Baz Castillo
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Magnus Westerlund
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Hadriel Kaplan
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Magnus Westerlund
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Hadriel Kaplan
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Colin Perkins
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Hadriel Kaplan
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Iñaki Baz Castillo
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Hadriel Kaplan
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Colin Perkins
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Magnus Westerlund
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Hadriel Kaplan
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Iñaki Baz Castillo
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Iñaki Baz Castillo
- Re: [rtcweb] consent freshness [was RE: STUN for … Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Magnus Westerlund
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Magnus Westerlund
- Re: [rtcweb] consent freshness [was RE: STUN for … Magnus Westerlund
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Hadriel Kaplan
- Re: [rtcweb] consent freshness [was RE: STUN for … Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] consent freshness [was RE: STUN for … Randell Jesup
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Magnus Westerlund
- Re: [rtcweb] consent freshness [was RE: STUN for … Magnus Westerlund
- Re: [rtcweb] consent freshness [was RE: STUN for … Randell Jesup
- Re: [rtcweb] STUN for keep-alive Cullen Jennings
- Re: [rtcweb] STUN for keep-alive Michael Tüxen
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Hadriel Kaplan
- Re: [rtcweb] consent freshness [was RE: STUN for … Magnus Westerlund
- Re: [rtcweb] consent freshness [was RE: STUN for … Harald Alvestrand
- Re: [rtcweb] consent freshness [was RE: STUN for … Stefan Håkansson LK
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Olle E. Johansson
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Iñaki Baz Castillo
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Harald Alvestrand
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Iñaki Baz Castillo
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Harald Alvestrand
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Iñaki Baz Castillo
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Harald Alvestrand
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Iñaki Baz Castillo