Re: [rtcweb] NAT behavior heuristics

Randell Jesup <randell-ietf@jesup.org> Sun, 05 August 2012 07:20 UTC

Return-Path: <randell-ietf@jesup.org>
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 A013621F8659 for <rtcweb@ietfa.amsl.com>; Sun, 5 Aug 2012 00:20:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.855
X-Spam-Level:
X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11]
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 Zfgt5eDVUpdJ for <rtcweb@ietfa.amsl.com>; Sun, 5 Aug 2012 00:20:12 -0700 (PDT)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 0A95A21F8624 for <rtcweb@ietf.org>; Sun, 5 Aug 2012 00:20:11 -0700 (PDT)
Received: from pool-173-49-141-60.phlapa.fios.verizon.net ([173.49.141.60] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <randell-ietf@jesup.org>) id 1Sxv8E-0007Wc-LJ for rtcweb@ietf.org; Sun, 05 Aug 2012 02:20:10 -0500
Message-ID: <501E1E40.8070203@jesup.org>
Date: Sun, 05 Aug 2012 03:18:24 -0400
From: Randell Jesup <randell-ietf@jesup.org>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <038b01cd70d6$8c5bc870$a5135950$@com> <CABkgnnW+pCnDZuYHDj6=7xdqRwM6AO48RrC1xhMrvFZbUBgtyw@mail.gmail.com> <04ff01cd7104$be09bed0$3a1d3c70$@com>
In-Reply-To: <04ff01cd7104$be09bed0$3a1d3c70$@com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Source:
X-Source-Args:
X-Source-Dir:
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: Sun, 05 Aug 2012 07:20:12 -0000

On 8/2/2012 7:15 PM, Dan Wing wrote:
>> -----Original Message-----
>> From: Martin Thomson [mailto:martin.thomson@gmail.com]
>> Sent: Thursday, August 02, 2012 4:02 PM
>> To: Dan Wing
>> 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.
>
> Yes.  PCP is new, somewhat like RTCWEB.
>
> There is an incentive for the existing CGNs, deployed by almost all
> 3G/LTE carriers around the world, to have their vendors add PCP
> support to those NATs, as it saves battery lifetime for their
> subscribers and reduces chatter on their network.  Incentives are
> well aligned for that to happen.
>
> I agree that home NATs, enterprise NATs, and enterprise firewalls
> do not have those same incentives.

And that's a rub, since in many/most cases, the 3G/LTE people will 
likely be talking to non-3G/LTE people, and if either side needs 
keepalives, then radio will be kept active.  Note we're talking 
long-term inactive media flows and an inactive (or rarely active) 
datachannel, such as a client using PeerConnection and DataChannels to 
keep a registration or empty conference alive, or various non-phone-like 
applications.

An alternative mechanism for keepalives might help - you can use 
short-TTL packets to prop the local router without letting the packet go 
all the way to the other end.  If the fixed-station PC uses this TTL 
trick, and the mobile unit uses PCP, the mobile unit can keep its radio off.

Short-TTL can be handy for reducing loads on servers, especially where 
the port needs to stay open with no real traffic for long periods (think 
SIP).

The local router is rarely more than 5-7 hops from a device, though 
there are pathological cases; this could be configured (and 
disableable).  There are also ways to do discovery on the local router; 
these might work better than discovery of UDP port binding time, which 
is known to not work.


-- 
Randell Jesup
randell-ietf@jesup.org