Re: [rtcweb] STUN for keep-alive

"Dan Wing" <dwing@cisco.com> Fri, 16 September 2011 19:32 UTC

Return-Path: <dwing@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 68B0B21F8CF6 for <rtcweb@ietfa.amsl.com>; Fri, 16 Sep 2011 12:32:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.162
X-Spam-Level:
X-Spam-Status: No, score=-103.162 tagged_above=-999 required=5 tests=[AWL=-0.563, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 aF8VlRIAFI6E for <rtcweb@ietfa.amsl.com>; Fri, 16 Sep 2011 12:32:11 -0700 (PDT)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB7B21F8D2C for <rtcweb@ietf.org>; Fri, 16 Sep 2011 12:32:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=5304; q=dns/txt; s=iport; t=1316201667; x=1317411267; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=SPCFHvemytKIuHnxa3GNzMKYGNQidK1T8MAuFnKhkEI=; b=S1QrmBmFew2n2v8J1yB1Thf16Jx+Q+bBV3PL41y36vdu8QoXxdAZ3QOa HAgcbMxMXhBQbBYAuwnmpVwNMvdTF6oYzkVYySYbWX/ixj7PNwyZaZKw2 Tcxkt4+RaSI31MBRre5I4D1b8IjSP0oTtBTpbBUa4smL8ojjqVhlIvs13 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: As0AANajc06rRDoJ/2dsb2JhbABBmGKBbI0Sd4FTAQEBAQMBAQEFCgEXEDQXAQMCCQ8CBAEBAScHGQ4VCgkIAQEEARILF4dZlXUBnjOGeASHb50n
X-IronPort-AV: E=Sophos;i="4.68,395,1312156800"; d="scan'208";a="2617415"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 16 Sep 2011 19:34:27 +0000
Received: from dwingWS ([10.32.240.194]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p8GJYQA8005733; Fri, 16 Sep 2011 19:34:26 GMT
From: "Dan Wing" <dwing@cisco.com>
To: "'Dzonatas Sol'" <dzonatas@gmail.com>, <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> <4E7392C6.9040604@gmail.com>
In-Reply-To: <4E7392C6.9040604@gmail.com>
Date: Fri, 16 Sep 2011 12:34:26 -0700
Message-ID: <095801cc74a7$a5362010$efa26030$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acx0nK6aUpNzwm2ISym/dE+mqDrM3gACrI6g
Content-Language: en-us
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 19:32:12 -0000

> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> Behalf Of Dzonatas Sol
> Sent: Friday, September 16, 2011 11:18 AM
> To: rtcweb@ietf.org
> Subject: Re: [rtcweb] STUN for keep-alive
> 
> 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. 

There are two types of NAT64:  stateless (which has the characteristic
you describe) and stateful (which would require keepalive traffic
for all the reasons today's NAPT44 devices require keepalives).  I
don't know what is meant by "when set up correctly".

-d

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