Re: [BEHAVE] (no subject)

[Simon Perreault <[e-mail]>]

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