Re: [rtcweb] STUN for keep-alive

Dzonatas Sol <dzonatas@gmail.com> Fri, 16 September 2011 18:13 UTC

Return-Path: <dzonatas@gmail.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 6610821F886A for <rtcweb@ietfa.amsl.com>; Fri, 16 Sep 2011 11:13:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.863
X-Spam-Level:
X-Spam-Status: No, score=-3.863 tagged_above=-999 required=5 tests=[AWL=-0.264, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 07UrJkJc-voJ for <rtcweb@ietfa.amsl.com>; Fri, 16 Sep 2011 11:13:17 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9F41E21F8801 for <rtcweb@ietf.org>; Fri, 16 Sep 2011 11:13:17 -0700 (PDT)
Received: by iaby26 with SMTP id y26so3127148iab.31 for <rtcweb@ietf.org>; Fri, 16 Sep 2011 11:15:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=kvm29/ceqhr8Rk9E/4NT1qrnvH+UfaCI3K0yNv7QThg=; b=OfSBmWOGsmupmxkkg9y8XiVGSsypwQrQtyYPQU82cbM2RhjHy3/OQnytn5ubrn/53/ 5RalMitaJ+eSCOYI+R2eSae/5MJHbEEZ1v6T7Dg0Oz4U1k6Iabjb4rSPUkjMKlFgbQvD W2pl5Zh7KlT3WKk8U+zzzd/uWZsUbVdyKikKM=
Received: by 10.231.51.4 with SMTP id b4mr4221534ibg.99.1316196932767; Fri, 16 Sep 2011 11:15:32 -0700 (PDT)
Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net. [70.133.70.225]) by mx.google.com with ESMTPS id z11sm10382028iba.6.2011.09.16.11.15.31 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 16 Sep 2011 11:15:31 -0700 (PDT)
Message-ID: <4E7392C6.9040604@gmail.com>
Date: Fri, 16 Sep 2011 11:17:42 -0700
From: Dzonatas Sol <dzonatas@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110818 Icedove/3.0.11
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CB0@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB264@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CEB@XMB-BGL-414.cisco.com> <092301cc749b$26223270$72669750$@com>
In-Reply-To: <092301cc749b$26223270$72669750$@com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
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: Fri, 16 Sep 2011 18:13:18 -0000

On 09/16/2011 11:04 AM, Dan Wing wrote:
>> -----Original Message-----
>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
>> Behalf Of Muthu Arul Mozhi Perumal (mperumal)
>> Sent: Wednesday, September 14, 2011 4:24 AM
>> To: Christer Holmberg; rtcweb@ietf.org
>> Subject: Re: [rtcweb] STUN for keep-alive
>>
>> |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.
>>      
> PCP can allow the client to know and control the NAT's UDP timeout,
> http://tools.ietf.org/html/draft-ietf-pcp-base-13#section-7.3.
>
> -d
>    

NAT64 doesn't have to worry about UDP content or timeouts like in IPv4 
when set up correctly, yet we can' expect everybody to use such 
configuration we consider correct. +1 for OAuth MAC for this reason.



>    
>> 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?
>>
>> Muthu
>>
>> |-----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 mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>      
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>    


-- 

---
<i>The wheel.</i metro-link=t dzonatasolyndra>