Re: [BEHAVE] (no subject)

Simon Perreault <simon.perreault@viagenie.ca> Fri, 28 June 2013 12:01 UTC

Return-Path: <simon.perreault@viagenie.ca>
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 1CA2C21F8493 for <behave@ietfa.amsl.com>; Fri, 28 Jun 2013 05:01:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level:
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, NO_RELAYS=-0.001]
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 EtYC8oVOgjBb for <behave@ietfa.amsl.com>; Fri, 28 Jun 2013 05:01:38 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE8221F9CF3 for <behave@ietf.org>; Fri, 28 Jun 2013 05:01:33 -0700 (PDT)
Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 9C4DE414F9; Fri, 28 Jun 2013 08:01:32 -0400 (EDT)
Message-ID: <51CD7B1B.5050301@viagenie.ca>
Date: Fri, 28 Jun 2013 14:01:31 +0200
From: Simon Perreault <simon.perreault@viagenie.ca>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6
MIME-Version: 1.0
To: ivan@cacaoweb.org
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> <e0a96b107000ac7705ae2a195b6ff1b5@cacaoweb.org>
In-Reply-To: <e0a96b107000ac7705ae2a195b6ff1b5@cacaoweb.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: Behave <behave@ietf.org>
Subject: Re: [BEHAVE] (no subject)
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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: Fri, 28 Jun 2013 12:01:44 -0000

Le 2013-06-27 18:46, ivan c a écrit :
>>> 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.

I think I'm starting to understand your proposal. Correct me if I'm 
wrong: you're proposing that NATs should be allowed to do port 
overloading as long as their default behaviour is EIM. They would only 
do port overloading if they're running out of ports. Is that correct?

That would solve the port scalability problem for busy NATs.

Your argument is that this kind of NAT can still be easily traversed by 
P2P applications, correct? Now, the thing I don't understand is how. You 
say "p2p application can simply retry with a new socket (on a new local 
endpoint) if the NAT happened to refuse or drop a packet".
- What packet gets dropped?
- How does the application know?
- How will using a new local endpoint result in no port overloading if 
the NAT is already busy enough that it has started overloading ports?

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

Ok. Then it seems nothing needs to be said about port preservation, correct?

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca