Re: [rtcweb] NAT behavior heuristics

Harald Alvestrand <harald@alvestrand.no> Mon, 06 August 2012 10:31 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 CE43621F863B for <rtcweb@ietfa.amsl.com>; Mon, 6 Aug 2012 03:31:49 -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 PxuztBuChfbs for <rtcweb@ietfa.amsl.com>; Mon, 6 Aug 2012 03:31:49 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 02D5021F85E6 for <rtcweb@ietf.org>; Mon, 6 Aug 2012 03:31:49 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 64A8039E0FA for <rtcweb@ietf.org>; Mon, 6 Aug 2012 12:31:46 +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 PzuNfuuHXx3O for <rtcweb@ietf.org>; Mon, 6 Aug 2012 12:31:45 +0200 (CEST)
Received: from [192.168.1.107] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id B79B539E062 for <rtcweb@ietf.org>; Mon, 6 Aug 2012 12:31:45 +0200 (CEST)
Message-ID: <501F9D18.4080909@alvestrand.no>
Date: Mon, 06 Aug 2012 12:31:52 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 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> <501E1E40.8070203@jesup.org> <913383AAA69FF945B8F946018B75898A1477C16C@xmb-rcd-x10.cisco.com>
In-Reply-To: <913383AAA69FF945B8F946018B75898A1477C16C@xmb-rcd-x10.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: Mon, 06 Aug 2012 10:31:50 -0000

On 08/05/2012 11:49 PM, Tirumaleswar Reddy (tireddy) wrote:
>> 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.
> If just 3G/LTE supports PCP and non-3G/LTE does not support PCP -> Any STUN indications coming from the non-3G can be dropped by the Mobile Network itself to avoid reaching the Mobile Node, since it knows NAT binding is alive using PCP.
>
1) the at-the-moment theory is that consent verification will use ICE 
Bind requests, not indications
2) if the mobile network drops these, the end node will assume that 
consent is withdrawn, and stop.

Agreed with those who argue that we shouldn't spend too much energy on 
optimizing for a moving target.