Re: [BEHAVE] (no subject)

ivan c <ivan@cacaoweb.org> Thu, 27 June 2013 16:46 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 20C2921F9E5B for <behave@ietfa.amsl.com>; Thu, 27 Jun 2013 09:46:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none]
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 BGxZP4mSOjfy for <behave@ietfa.amsl.com>; Thu, 27 Jun 2013 09:46:04 -0700 (PDT)
Received: from mail.cacaoweb.org (mail.cacaoweb.org [46.105.102.78]) by ietfa.amsl.com (Postfix) with ESMTP id E703721F99FE for <behave@ietf.org>; Thu, 27 Jun 2013 09:46:00 -0700 (PDT)
Received: from www-data by mail.cacaoweb.org with local (Exim 4.72) (envelope-from <ivan@cacaoweb.org>) id 1UsFLX-0001Sk-1y; Thu, 27 Jun 2013 18:46:59 +0200
To: Simon Perreault <simon.perreault@viagenie.ca>
X-PHP-Originating-Script: 0:func.inc
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Date: Thu, 27 Jun 2013 18:46:59 +0200
From: ivan c <ivan@cacaoweb.org>
Organization: cacaoweb
In-Reply-To: <51CC6144.3080000@viagenie.ca>
References: <CB1B483277FEC94E9B58357040EE5D02325A6E93@xmb-rcd-x15.cisco.com> <2f7dce8264c8a9a72640629502a44295@cacaoweb.org> <51C1681A.5030909@viagenie.ca> <f8741fad1af1cee094de9c59408b7425@cacaoweb.org> <51C40374.8080403@viagenie.ca> <21e25b7ae1501228a67656b2fa4bc009@cacaoweb.org> <51CAA20F.4070307@viagenie.ca> <88c0ada2b8ebad078fb249ac6572fd8b@cacaoweb.org> <51CBD188.4060408@viagenie.ca> <fc3c7389e9fc7afc9201f0516de436a7@cacaoweb.org> <51CC2ED4.7090506@viagenie.ca> <4d2e082fd02ce46cd003631e8ca8eae9@cacaoweb.org> <014f01ce7341$e5416620$afc43260$@comcast.net> <c5d2c0cac921875729b4ad89a290fcf5@cacaoweb.org> <51CC52AC.8010702@viagenie.ca> <4a641d08eccfd84d2882e32369ad8e61@cacaoweb.org> <51CC6144.3080000@viagenie.ca>
Message-ID: <e0a96b107000ac7705ae2a195b6ff1b5@cacaoweb.org>
X-Sender: ivan@cacaoweb.org
User-Agent: RoundCube Webmail/0.3.1
Cc: Behave <behave@ietf.org>
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: Thu, 27 Jun 2013 16:46:09 -0000

On Thu, 27 Jun 2013 17:59:00 +0200, Simon Perreault
<simon.perreault@viagenie.ca> wrote:
> Le 2013-06-27 17:29, ivan c a écrit :
>>> We know that port overloading is desirable for a number of reasons.
>>> What we need to argue is why the undesirable effects of port
overloading
>>> do not apply or can be ignored.
>>
>> Definitely, this is the main point of our argument.
>> I think we have progressed in this argument and provided useful
material.
>> In this post:
>> http://www.ietf.org/mail-archive/web/behave/current/msg10896.html , I
>> explain (among other things), why the TCP Hole Punching Protocol is not
>> affected by the rare cases of collision due to port overloading. The
>> application simply retries with a new TCP socket (on a new local
>> endpoint).
> 
> ...as long as the NAT does port preservation, right?
> 

No, I meant it in the general case with port overloading, with or without
TCP port preservation.
As you know, port overloading breaks the EIM requirement in the general
case. This is why port overloading is a MUST NOT in the existing RFCs.
But since collisions are supposed to be rare, p2p application can simply
retry with a new socket (on a new local endpoint) if the NAT happened to
refuse or drop a packet.


> If so, the problem I see is that CGNs do not / can not / will not do 
> port preservation, as a few people already pointed out.

Sure, regarding port preservation, on very busy CGNs it will surely not be
granted all the time. But they are free to use the port allocation scheme
they like. As you say, I assume a lot of CGNs won't support it.
Port preservation should probably be an optional feature (especially for
home NATs, that generally already have it). It is not necessarily related
to port overloading.
Port overloading, i feel, should probably be an optional feature too,
since it is used in the wild and has limited impact on TCP Hole Punching.
I'm not a NAT implementer though and thus my voice is not the most
important here, as I see it as a NAT only feature that doesn't seriously
affect p2p applications.


Hope this helps clarifying the point.



-- 
_Ivan Chollet_