Re: [rtcweb] NAT behavior heuristics

"Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com> Sat, 04 August 2012 00:04 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 86A5A21E8055 for <rtcweb@ietfa.amsl.com>; Fri, 3 Aug 2012 17:04:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.556
X-Spam-Level:
X-Spam-Status: No, score=-10.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 nRY-InOZivJi for <rtcweb@ietfa.amsl.com>; Fri, 3 Aug 2012 17:04:55 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id F081521E803D for <rtcweb@ietf.org>; Fri, 3 Aug 2012 17:04:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5769; q=dns/txt; s=iport; t=1344038695; x=1345248295; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=m4+nc+8goYxvNRU9Qe2s9GWwtAqzRNU+n9ujiUiXA1w=; b=fvovjYvWgFVPDh6lAiWPtIUsLPm28N4nDTS74V981lQDYHnq6/Yv+zZ1 ltGJ1HpE4/4KPOJ1gdElks6TRYHgPyoCqjXT9XzEcrKE+WwnWQXo0eBNU HnaYusR9DFsOymlPjjulGy59Pw3KuG53TteylhjzN48DMnBYoUkrlUQSr U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAOplHFCtJV2Z/2dsb2JhbABFuTuBB4IgAQEBBAEBAQ8BJzQXBAIBCBEEAQELFAkHJwsUCQgCBAESCBqHawucVqASi0gFFoYJYAOWXo0TgWaCX4FWBw
X-IronPort-AV: E=Sophos;i="4.77,709,1336348800"; d="scan'208";a="105376545"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 04 Aug 2012 00:04:54 +0000
Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q7404seX018923 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 4 Aug 2012 00:04:54 GMT
Received: from xmb-rcd-x02.cisco.com ([169.254.4.113]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0283.003; Fri, 3 Aug 2012 19:04:54 -0500
From: "Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com>
To: Harald Alvestrand <harald@alvestrand.no>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: [rtcweb] NAT behavior heuristics
Thread-Index: AQHNcQLmZq9mQPoftU6IiiFi63YLnpdHtxfQgADTdACAADrF8A==
Date: Sat, 4 Aug 2012 00:04:53 +0000
Message-ID: <E721D8C6A2E1544DB2DEBC313AF54DE203E5B050@xmb-rcd-x02.cisco.com>
References: <038b01cd70d6$8c5bc870$a5135950$@com> <CABkgnnW+pCnDZuYHDj6=7xdqRwM6AO48RrC1xhMrvFZbUBgtyw@mail.gmail.com> <E721D8C6A2E1544DB2DEBC313AF54DE203E59C1A@xmb-rcd-x02.cisco.com> <501BEDAE.8090005@alvestrand.no>
In-Reply-To: <501BEDAE.8090005@alvestrand.no>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.65.72.165]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19084.001
x-tm-as-result: No--43.626600-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [rtcweb] NAT behavior heuristics
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: Sat, 04 Aug 2012 00:04:56 -0000

|Don't forget that if you want to shut down a flow according to 
|RTP rules, you have to stop sending RTCP on it, which, again 
|according to RTP rules, will declare the flow ended after a 
|timeout.

The idea is to completely shut down the flow. The RTP rules will ensure that the peer times out and releases its resources.

Muthu 

|-----Original Message-----
|From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald Alvestrand
|Sent: Friday, August 03, 2012 8:57 PM
|To: rtcweb@ietf.org
|Subject: Re: [rtcweb] NAT behavior heuristics
|
|Don't forget that if you want to shut down a flow according to RTP
|rules, you have to stop sending RTCP on it, which, again according to
|RTP rules, will declare the flow ended after a timeout.
|
|If you want to have the flow "active but not sending", you have to go on
|sending RTCP SR's, reporting that "I still have this flow, but I
|deliberately did not send any packets on it" - which of course will keep
|the radio awake.
|
|If the flow is regarded as ended at all layers, resumption becomes a
|non-issue; you just add a new flow when the time comes.
|
|On 08/03/2012 12:58 AM, Muthu Arul Mozhi Perumal (mperumal) wrote:
|> |We might want to consider other options for things like power saving
|> |in addition to this.  One option that springs to mind is the ability
|> |to explicitly shut down streams that aren't in use and pay the price
|> |for warm-up.
|>
|> I think that can be done by slightly tweaking the consent freshness test in draft-muthu-behave-
|consent-freshness-01. We can also combine it with the session liveness test and optimize everything.
|Here is the algorithm I have in mind:
|>
|> The browser starts two timers after ICE concludes:
|> - A consent timer t1 for 15 sec (configurable in the browser)
|> - A liveness timer t2 for 5 sec (configurable by the JS)
|>
|> When t1 expires:
|> If nothing except consent freshness request(s) was sent in the last x sec then
|>     goto power_saving_mode.
|> Else // We has been sending media on the candidate pair.
|>     If a STUN transaction isn't already active then
|>        Send a consent freshness request.
|>     If the transaction fails then
|>        goto power_saving_mode.
|>     Else // The transaction succeeds
|>        Reset t1.
|>
|> When t2 expires:
|> If nothing was received since the last liveness test then
|>     If a STUN transaction isn't already active then
|>        Send a liveness request.
|>     If the transaction fails then
|>        Notify the JS.
|>     Else // The transaction succeeds
|>        Reset t2.
|>
|> power_saving_mode:
|>     Stop sending everything on that candidate pair.
|>     Stop both timers.
|>     Notify the JS.
|>
|> Notes:
|> The JS is responsible for restarting ICE in the power_saving_mode.
|> Consent freshness and liveness requests are STUN binding requests.
|> The default value for t1 is the same as the default for ICE keepalives (section 10 of RFC5245).
|> The default value for x is 60 sec (configurable by the JS).
|>
|> By carefully choose t1, t2 and x we can:
|> 1. Make it work for existing NATs.
|> 2. Interoperate with existing ICE/ICE-lite implementations.
|> 3. Save battery.
|> 4. Achieve good user experience.
|>
|> Comments welcome.
|>
|> Muthu
|>
|> |-----Original Message-----
|> |From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Martin Thomson
|> |Sent: Friday, August 03, 2012 4:32 AM
|> |To: Dan Wing (dwing)
|> |Cc: rtcweb@ietf.org
|> |Subject: Re: [rtcweb] NAT behavior heuristics
|> |
|> |I assume that this applies only to the NAT that doesn't exist yet and
|> |that we will have to live with status quo (and the current keep-alive
|> |recommendations) until PCP becomes bountiful.
|> |
|> |We might want to consider other options for things like power saving
|> |in addition to this.  One option that springs to mind is the ability
|> |to explicitly shut down streams that aren't in use and pay the price
|> |for warm-up.  Optimizations to candidate pair select at warm-up might
|> |be handy in this case.
|> |
|> |On 2 August 2012 10:45, Dan Wing <dwing@cisco.com> wrote:
|> |> In today's RTCWEB meeting I said that NAT heuristics do not work reliably,
|> |> especially if a NAT is busy (high CPU or lots of ports consumed), but there
|> |> are other situations with a NAT that cause heuristics to be inaccurate.  The
|> |> IETF document regarding this is http://tools.ietf.org/html/rfc5780, and be
|> |> sure to read its Applicability Statement in Section 1,
|> |> http://tools.ietf.org/html/rfc5780#section-1.
|> |>
|> |> An explicit protocol, such Port Control Protocol (PCP, draft-ietf-pcp-base)
|> |> is the only reliable way to communicate with a NAT and reduce application
|> |> keepalive traffic.  Several of us have noticed the need to document exactly
|> |> how PCP can be reliably used to reduce UDP keepalive traffic.  We will write
|> |> down those details before the next IETF, probably in an Internet Draft.
|> |>
|> |> -d
|> |>
|> |>
|> |> _______________________________________________
|> |> 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
|> _______________________________________________
|> 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