Re: [rtcweb] NAT behavior heuristics

Harald Alvestrand <harald@alvestrand.no> Fri, 03 August 2012 15:26 UTC

Return-Path: <harald@alvestrand.no>
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 1B18F21F8D33 for <rtcweb@ietfa.amsl.com>; Fri, 3 Aug 2012 08:26:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 lu7l51-Vckja for <rtcweb@ietfa.amsl.com>; Fri, 3 Aug 2012 08:26:42 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id AD10421F8CAD for <rtcweb@ietf.org>; Fri, 3 Aug 2012 08:26:41 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 33ABD39E179 for <rtcweb@ietf.org>; Fri, 3 Aug 2012 17:26:39 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6QqNGEOJDMli for <rtcweb@ietf.org>; Fri, 3 Aug 2012 17:26:36 +0200 (CEST)
Received: from [192.168.16.101] (dhcp-442d.meeting.ietf.org [130.129.68.45]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id D39D439E056 for <rtcweb@ietf.org>; Fri, 3 Aug 2012 17:26:35 +0200 (CEST)
Message-ID: <501BEDAE.8090005@alvestrand.no>
Date: Fri, 03 Aug 2012 08:26:38 -0700
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <038b01cd70d6$8c5bc870$a5135950$@com> <CABkgnnW+pCnDZuYHDj6=7xdqRwM6AO48RrC1xhMrvFZbUBgtyw@mail.gmail.com> <E721D8C6A2E1544DB2DEBC313AF54DE203E59C1A@xmb-rcd-x02.cisco.com>
In-Reply-To: <E721D8C6A2E1544DB2DEBC313AF54DE203E59C1A@xmb-rcd-x02.cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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: Fri, 03 Aug 2012 15:26:43 -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.

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