Re: [BEHAVE] (no subject)

[ivan c <[e-mail]>]

On Thu, 27 Jun 2013 17:59:00 +0200, Simon Perreault
<[e-mail]> 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_