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