Re: [rtcweb] NAT behavior heuristics

Cameron Byrne <> Tue, 07 August 2012 15:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C29C221F86DE for <>; Tue, 7 Aug 2012 08:11:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.464
X-Spam-Status: No, score=-3.464 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oawKcLhqJMs5 for <>; Tue, 7 Aug 2012 08:11:04 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8CFFA21F8665 for <>; Tue, 7 Aug 2012 08:11:03 -0700 (PDT)
Received: by lahm15 with SMTP id m15so2357480lah.31 for <>; Tue, 07 Aug 2012 08:11:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=by2A7zQ1tRzhdLxi7iiV+z1dCvhNHiUNPOaMb00jp5U=; b=mx870O04PVeK51L0djPN3rh7tNCf0JAe6FTpH/Qei0FcFik6ixZpMYj78JgNzDeQNT fFjUCs3z5V/EJ+ScEjhZoZSZMZv0N+WQzG7/VfYTjGY8+2ce6Klf6tswvDIIKTK71Mus qIs+9s3sjdnIX0hjzgdBQtuhOy+P76/SbMVg8k4H64WuY+LPM4e6u30GG6fw5uCmAYYN jrgiOfam6pWU9tlZSzkvjj4EKiCP9SB4KLpUfiLdetMeNbdInwYemYZ96xYopAzFVS4y tfhzZJzrAtpySNoo4HwmE47IYZjuGIDOslhO2ku7gqY/trvym1bXYPaZps1YhPVioAkU R5qw==
MIME-Version: 1.0
Received: by with SMTP id f3mr6387716lbm.59.1344352262404; Tue, 07 Aug 2012 08:11:02 -0700 (PDT)
Received: by with HTTP; Tue, 7 Aug 2012 08:11:02 -0700 (PDT)
Received: by with HTTP; Tue, 7 Aug 2012 08:11:02 -0700 (PDT)
In-Reply-To: <>
References: <038b01cd70d6$8c5bc870$a5135950$@com> <> <04ff01cd7104$be09bed0$3a1d3c70$@com> <> <> <> <> <>
Date: Tue, 7 Aug 2012 08:11:02 -0700
Message-ID: <>
From: Cameron Byrne <>
Content-Type: multipart/alternative; boundary=bcaec554d23e0dbcc604c6ae6751
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: Tue, 07 Aug 2012 15:11:06 -0000

On Aug 7, 2012 7:13 AM, <> wrote:
> Hi Cameron,
> Cameron Byrne wrote:
> >
> >I asked around in Vancouver about PCP, and all the operators i spoke to
> >no-plans, no motivation.  But, that was a small sample.
> This is probably a fair assessment about the concrete plans. Most mobile
operators don't even follow IETF much, so I doubt that they have even heard
about PCP so far. There are however a few operators, where at least the
research and standardization people have been interested in PCP (as
witnessed by I think
some operators are also proposing PCP to be included in the 3GPP specs
(release 12). It is hard to say how much that means in the real world, but
at least I'd expect we could find a few operators willing to do
real-network trials withing the next 12 months.
> Personally I see PCP as a very useful tool in the cellular access
environment, for probing the NAT/FW timers and in the best case even
setting them. It will be a major chicken-and-egg situation between apps,
mobile OS's and the networks, to get anything into use. I think we should
still do our best to overcome it. I agree that RTCWeb or anyone else should
not rely on PCP (or any similar mechanim), but have the ability to make use
of it if it happens to be available.
> I'm unconvinced IPv6 will help at all in this case. How do you know how
long the FW on the path will keep its state up without keepalives? It will
probably be the same as for NATs: In some networks timeout is 2 minutes,
while in others 60 minutes. Having something like PCP to check out that it
indeed is 60 min. would be extremely helpful. While most app developers
might not be willing/able to optimize for battery/mobile, there are already
some that are doing a good job. So there is hope that the new mechanisms
would get some traction.

I know of one large USA mobile operator that is not SPI firewalling or
tracking state for ipv6 mobiels, so this is not a problem for them.

If operators choose to statefully inspect user traffic, those cost and
limitations are assumed as part of the cost and service definition from the
mobile operator.

IMHO, SPI FW in ipv6 is not prudent or cost justified in mobile networks.


> Markus
> >-----Original Message-----
> >From: [] On Behalf
> >Of ext Cameron Byrne
> >Sent: 06 August, 2012 01:22
> >To: Tirumaleswar Reddy (tireddy)
> >Cc: Randell Jesup;;
> >Subject: Re: [rtcweb] NAT behavior heuristics
> >
> >On Sun, Aug 5, 2012 at 3:05 PM, Tirumaleswar Reddy (tireddy)
> ><> wrote:
> >>> Fyi. I have not seen any traction for pcp anywhere in the mobile
> >>
> >>
> >usage of PCP in Mobile Deployments.
> >>
> >> --Tiru.
> >>
> >
> >Yep, that's  an I-D.
> >
> >And, it says things like "Without
> >   the particular considerations , PCP may not provide desirable
> >   outcomes.  Some default behaviours may even cause negative impacts or
> >   system failures in a mobile environment.  "
> >
> >Got an operators with a timeline on supporting it?  How about a mobile OS
> >that plans to support PCP, because you will need both.  And, that would
> >interesting information.
> >
> >I asked around in Vancouver about PCP, and all the operators i spoke to
> >no-plans, no motivation.  But, that was a small sample.
> >
> >In any event, my only point is that RTCWEB should NOT be counting on
PCP.  If
> >PCP is a tool you have, use it.  My point: it is not a tool you have.
> >
> >CB
> >_______________________________________________
> >rtcweb mailing list
> >
> >