Re: [rtcweb] STUN for keep-alive
Christer Holmberg <christer.holmberg@ericsson.com> Wed, 14 September 2011 13:05 UTC
Return-Path: <christer.holmberg@ericsson.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 7F1D021F8CB6 for <rtcweb@ietfa.amsl.com>; Wed, 14 Sep 2011 06:05:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.525
X-Spam-Level:
X-Spam-Status: No, score=-6.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 1BlET9rmISic for <rtcweb@ietfa.amsl.com>; Wed, 14 Sep 2011 06:05:34 -0700 (PDT)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id C1CEA21F8CCA for <rtcweb@ietf.org>; Wed, 14 Sep 2011 06:05:33 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c47ae000000b17-bd-4e70a71da6bf
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 84.16.02839.D17A07E4; Wed, 14 Sep 2011 15:07:42 +0200 (CEST)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 14 Sep 2011 15:07:41 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Date: Wed, 14 Sep 2011 15:07:40 +0200
Thread-Topic: [rtcweb] STUN for keep-alive
Thread-Index: Acxyw30r82gF7xzoSe2t1rt6OG8s+wAA6iNwAABiKWAAAWch4AAAqu/QAABRLRAAAxn+QA==
Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233EDB3E5@ESESSCMS0356.eemea.ericsson.se>
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> <1D062974A4845E4D8A343C653804920206648D0F@XMB-BGL-414.cisco.com>
In-Reply-To: <1D062974A4845E4D8A343C653804920206648D0F@XMB-BGL-414.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
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 13:05:35 -0000
Hi, >>|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). Yes, but at the end of the day something has to be sent in order to keep the NAT binding open. >>|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. I believe it knows when to expect those. But, in any case, the main reason behind the proposal is to decrease the number of STUN requests. > 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. Sure, I was talking about the case where the gateway terminates ICE and STUN. Regards, Christer > |-----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