IETF Logo Mail Archive

Re: [rtcweb] NAT behavior heuristics

"Dan Wing" <dwing@cisco.com> Thu, 02 August 2012 23:15 UTC

Return-Path: <dwing@cisco.com>
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 E64E521E804A for <rtcweb@ietfa.amsl.com>; Thu, 2 Aug 2012 16:15:47 -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 gJd6UK+23O0q for <rtcweb@ietfa.amsl.com>; Thu, 2 Aug 2012 16:15:47 -0700 (PDT)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id D107D21E8039 for <rtcweb@ietf.org>; Thu, 2 Aug 2012 16:15:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2351; q=dns/txt; s=iport; t=1343949346; x=1345158946; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=7PqDarZ/4ALZgjlXKsEHXsa2K1M4qK5oFc5B/4qSDjI=; b=dvhay72V0WZTYFAFwWV/fmTaGmlJT0F8533WxpwvlKx1sJwvwqvfxdPT xvVNDBFAAbQW7VmfV8NFJGIA//ch0jOL39Pfgr3GkF104N7KmwJS0oWsm x1npIRNkGWFnjoiFFlBUUqSm/Nxb3YD/VW8p9qHUCBiqEBfnz8IG0+8AX I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhIFADMIG1CQ/khM/2dsb2JhbABFhXujY489gQeCIAEBAQMBAQEBBQoBEAc9BwsFBwEDAgkPAgQBAQECAiMDAgIZCAYVCgkIAQEEEwsXh1wDBgYLnHqNGYlSDYlOgSGJQmcFFoVXgRIDiE2FDIYbgmeJdoMdgWaCfw
X-IronPort-AV: E=Sophos;i="4.77,703,1336348800"; d="scan'208";a="75752180"
Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 02 Aug 2012 23:15:44 +0000
Received: from dwingWS (sjc-vpn6-1214.cisco.com [10.21.124.190]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q72NFhQ0002326; Thu, 2 Aug 2012 23:15:44 GMT
From: Dan Wing <dwing@cisco.com>
To: 'Martin Thomson' <martin.thomson@gmail.com>
References: <038b01cd70d6$8c5bc870$a5135950$@com> <CABkgnnW+pCnDZuYHDj6=7xdqRwM6AO48RrC1xhMrvFZbUBgtyw@mail.gmail.com>
In-Reply-To: <CABkgnnW+pCnDZuYHDj6=7xdqRwM6AO48RrC1xhMrvFZbUBgtyw@mail.gmail.com>
Date: Thu, 02 Aug 2012 16:15:43 -0700
Message-ID: <04ff01cd7104$be09bed0$3a1d3c70$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac1xAunMGd6HFGy9RJmomYLEhqfaSQAAA9tA
Content-Language: en-us
Cc: rtcweb@ietf.org
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: Thu, 02 Aug 2012 23:15:48 -0000

> -----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.

> 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.

Such as draft-westerlund-avtext-rtp-stream-pause?

-d


> 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

v2.23.0 | Report a Bug | By Email