Re: [BEHAVE] (no subject)

[ivan c <[e-mail]>]

On Wed, 19 Jun 2013 10:13:14 +0200, Simon Perreault
<[e-mail]> wrote:
> Le 2013-06-18 22:33, ivan c a écrit :
>> The discussion here is not about UDP. UDP port preservation should
>> generally not be implemented by NATs, as it could generate conflicts
>> when 2
>> internal hosts using the same local port, each with a session to the
same
>> endpoint. This would break end-to-end connectivity in rare cases, as
>> there
>> is no fallback mechanism (as opposed to TCP).
> 
> Please explain how TCP is not subject to the same problem.
> 

This question is really about Port Overloading and is the crux of the
discussion, so i'm giving a short answer and a longer, more detailed
answer.
I voluntarily leave the long answer on this mailing-list, so it can
provide raw material for the draft later on.


THE SHORT ANSWER:
Port overloading (UDP or TCP) introduces the small possibility of a
non-deterministic behavior of the NAT: the fallback on EDM in the event of
a 5-tuple conflict.
It's a rare event, and only affects p2p applications, who are already
prepared to deal with it. After all, a large part of NATs in the wild
aren't cooperative, so p2p applications always have fallback mechanisms in
place. 
Beacause of the potential benefits of port overloading for CGNs, this
should be a no brainer.
In short, port overloading is fine for both UDP and TCP and won't break
any p2p application.
That been said, the use case for NAT port overloading was always only TCP,
as applications do not need to create that many local endpoints for UDP. So
let's not even bother with the corner cases for UDP for simplicity sake and
tell the NAT not do port overloading for UDP.
Conclusion: 
- UDP port overloading is not particularly useful, Req 3 of RFC 4787 is
fine.
- TCP port overloading can be very useful, RFC 5382 should mention support
for it.


THE LONGER ANSWER:
There is one major difference between UDP and TCP from the application
point of view:

(1) one UDP socket (local endpoint) can have multiple communication
sessions. (with multiple remote endpoints)
(2) one TCP socket can have only one session.

Condition (2) is not implied by RFC 793, but is enforced by POSIX. This
originates from the fact that Unix had a special recv() function for
connected socket, as opposed to recvfrom() for general sockets. POSIX later
standardized on this Unix behavior. This Unix idiosyncrasy prevents
sessions multiplexing for connected sockets.

Consequence: 
Applications don't need to use more than one UDP local endpoint, but need
to use many TCP local endpoints.

The impact on applications behavior:
For UDP, a p2p application will tend to multiplex all its p2p sessions
over one UDP socket (actually, some use 2 or 3 sockets for convenience).
This is what you observe with Skype, uTorrent, etc. but is applicable to
virtually all applications: it saves scarce resources (ports) and is
considered good design.
Unfortunately, since POSIX doesn't support the same thing for TCP, and a
large number of TCP sockets will be created by the application, on many
local endpoints, as you have witnessed for most "torrent-like"
applications.

Consequence (1):
The use case for port overloading should be TCP, not UDP.


Back to NAT port overloading. A collision occurs when 2 sessions share the
same 5-tuple. It is usually a rare event. Let's look at the corner case of
when a collision occurs, with p being the probability of a collision:
- NAT fallbacks on EDM for this particular session (note:
non-deterministic behavior from the application pov, with probability p)
- two possible outcomes for the application:
  1) session initiation succeeds, OK.
  2) session initiation fails, application fallbacks on the following:
     * create a new socket (with a new local endpoint) and restart.
Probability of success increases exponentially in (1-p^n) at each re-try.
     * use another fallback mechanism (UPnP, relaying, etc.), but this is
out of scope and not part of the TCP Hole Punching protocol.

Note 1: The session usually often succeeds when NAT fallbacks to EDM. It
only fails in the case where the remote endpoint is also behind a NAT.

Note 2: Here, the slight probability of failure for a connection attempt
is corrected by the TCP Hole Punching protocol as a whole.
(Analogy with TCP: the non-deterministic behavior introduced by packet
loss is abstracted away by the TCP layer, by resending the lost packets)

The failure case when the session fails is dealt with by the more
complicated code path in 2). Here the application creates a new socket.
What it implies, in both UDP and TCP cases:
UDP: creating a new socket for UDP is ok, but an annoyance. Goes against
good design practices.
TCP: creating a new socket is ok, this is what the application is doing
anyway for each new session.


Conclusion:
UDP: there is not much of a case for port overloading, and the more
complicated behavior path could possibly go against application good design
practices.
TCP: port overloading fits well with the TCP Hole Punching protocol.


In my opinion, although we can leave the requirements for UDP as they are
for the sake of simplicity, we need to write about the possibility of port
overloading for TCP in the documents.



-- 
_Ivan Chollet_