Re: [rtcweb] NAT behavior heuristics

"Muthu Arul Mozhi Perumal (mperumal)" <> Fri, 03 August 2012 07:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 191A721F8D1B for <>; Fri, 3 Aug 2012 00:58:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uau6d9Cy4+nP for <>; Fri, 3 Aug 2012 00:58:57 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id DCD5A21F8D3C for <>; Fri, 3 Aug 2012 00:58:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3995; q=dns/txt; s=iport; t=1343980737; x=1345190337; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=PMZ6CPcAD9XuZKYhay0R80T12gMzQ2I+DOFCjD5Vygg=; b=WzwHyrgpBKS2NPKB6J8DrGu/0tlNzQqYr0ZQyrvjRew1AZW+dmKIbqdM 603VyMm4kacDE7Gp0g+f/+vm5h/t4ajyAo9L+/4sATfQO/+VXKLsIWwTY JkE6wszkzIdxKOa9WAvnBa+Chwc1MbP7LfLgn7cZkb2AlQnNxl/aw3+6e 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.77,705,1336348800"; d="scan'208";a="108125911"
Received: from ([]) by with ESMTP; 03 Aug 2012 07:58:56 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id q737wull007394 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 Aug 2012 07:58:56 GMT
Received: from ([]) by ([]) with mapi id 14.02.0298.004; Fri, 3 Aug 2012 02:58:56 -0500
From: "Muthu Arul Mozhi Perumal (mperumal)" <>
To: Martin Thomson <>, "Dan Wing (dwing)" <>
Thread-Topic: [rtcweb] NAT behavior heuristics
Thread-Index: AQHNcQLmZq9mQPoftU6IiiFi63YLnpdHtxfQ
Date: Fri, 3 Aug 2012 07:58:55 +0000
Message-ID: <>
References: <038b01cd70d6$8c5bc870$a5135950$@com> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-tm-as-product-ver: SMEX-
x-tm-as-result: No--40.231500-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
Cc: "" <>
Subject: Re: [rtcweb] NAT behavior heuristics
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 03 Aug 2012 07:58:58 -0000

|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.
   Stop sending everything on that candidate pair. 
   Stop both timers.
   Notify the JS. 

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.


|-----Original Message-----
|From: [] On Behalf Of Martin Thomson
|Sent: Friday, August 03, 2012 4:32 AM
|To: Dan Wing (dwing)
|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 <> 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, and be
|> sure to read its Applicability Statement in 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 mailing list