Re: [BEHAVE] (no subject)

ivan c <ivan@cacaoweb.org> Tue, 18 June 2013 17:10 UTC

Return-Path: <ivan@cacaoweb.org>
X-Original-To: behave@ietfa.amsl.com
Delivered-To: behave@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4344121F9B7E for <behave@ietfa.amsl.com>; Tue, 18 Jun 2013 10:10:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.524
X-Spam-Level:
X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599]
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 44OFeA4VhB9K for <behave@ietfa.amsl.com>; Tue, 18 Jun 2013 10:10:06 -0700 (PDT)
Received: from mail.cacaoweb.org (mail.cacaoweb.org [46.105.102.78]) by ietfa.amsl.com (Postfix) with ESMTP id EB59521F9B7D for <behave@ietf.org>; Tue, 18 Jun 2013 10:10:05 -0700 (PDT)
Received: from www-data by mail.cacaoweb.org with local (Exim 4.72) (envelope-from <ivan@cacaoweb.org>) id 1UozQm-0005Q5-Ig; Tue, 18 Jun 2013 19:10:56 +0200
To: Behave <behave@ietf.org>
X-PHP-Originating-Script: 0:func.inc
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Date: Tue, 18 Jun 2013 19:10:56 +0200
From: ivan c <ivan@cacaoweb.org>
Organization: cacaoweb
In-Reply-To: <CB1B483277FEC94E9B58357040EE5D02325A69CD@xmb-rcd-x15.cisco.com>
References: <CB1B483277FEC94E9B58357040EE5D02325A69CD@xmb-rcd-x15.cisco.com>
Message-ID: <29cbc62347efa3a4efcf6105d04e531d@cacaoweb.org>
X-Sender: ivan@cacaoweb.org
User-Agent: RoundCube Webmail/0.3.1
Subject: Re: [BEHAVE] (no subject)
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ivan@cacaoweb.org
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Jun 2013 17:10:11 -0000

Hi Senthil,

See my comments below.

On Tue, 18 Jun 2013 16:16:33 +0000, "Senthil Sivakumar (ssenthil)"
<ssenthil@cisco.com> wrote:

> 
> I just want to add that I did a port preservation implementation a while
> ago, but realized that the number of times that the ports couldn¹t be
> preserved were getting more and more. Even though this wasn't causing
any
> application behavior issues, the customers were complaining because they
> construed that as NAT not working properly, (whether their assumption
that
> is right or wrong is a different discussion), so we ended up not using
the
> port preservation as a default behavior in later implementations. It
also
> improves the performance.
> 

Are you talking about UDP port preservation? I think we all agree UDP port
preservation is not necessary, as long as the NAT is EIM for UDP.
About TCP port preservation, most NAT implementations have it. In some
countries (like France), all ISP-provided gateways have it.
As you note, TCP port preservation improves latency and thus performance,
when compared to the alternative of using a STUNT server.
It does not need the intermediate step of contacting the STUNT server to
perform TCP port prediction.


> 
>>
>>- Port preservation is not applicable to CGN, where a subscriber often
>>only has access to a limited range of external ports.
> 
> Exactly, with the allocation of port sets in CGN, it becomes very
> difficult to do any kind of port preservation.
> 

Nope, you would need to elaborate on this.
The probability that of an internal port collision is high because of the
birthday paradox, but port overloading is perfectly acceptable, and when a
full collision occurs (when internal ports and remote endpoints are the
same for two outgoing TCP connections), which is supposed to be a rare
event, the CGN can fallback on EDM or simply drop the connection.



>>
>>- There are ways to improve the scalability of EIM without killing it.
>>I've been advocating for some time that NATs should be allowed to use
>>EDM for protocols that they know will not break, with EIM as a default.
>>For example, using EDM for TCP port 80 and UDP port 53 is easy,
>>harmless, and has a big impact.
> 
> For allowing EDM, one has to know their applications they are using, but
> as you say port 80 can work well with EDM.
> 

Exactly, see my message to Simon for a more in-depth discussion about this
topic.



-- 
_Ivan Chollet_