Re: [BEHAVE] (no subject)

Simon Perreault <> Fri, 21 June 2013 07:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EF91411E8108 for <>; Fri, 21 Jun 2013 00:40:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.586
X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id I6DaNFkkVoMr for <>; Fri, 21 Jun 2013 00:40:45 -0700 (PDT)
Received: from ( [IPv6:2620:0:230:8000::2]) by (Postfix) with ESMTP id 84FDE11E8166 for <>; Fri, 21 Jun 2013 00:40:45 -0700 (PDT)
Received: from (unknown [IPv6:2620:0:230:2001::1000]) by (Postfix) with ESMTPSA id 604F640426 for <>; Fri, 21 Jun 2013 03:40:37 -0400 (EDT)
Message-ID: <>
Date: Fri, 21 Jun 2013 09:40:36 +0200
From: Simon Perreault <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [BEHAVE] (no subject)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 21 Jun 2013 07:40:47 -0000

Le 2013-06-20 20:27, ivan c a écrit :
> On Wed, 19 Jun 2013 10:13:14 +0200, Simon Perreault
> <> 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.
> 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.
> 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.

I don't understand how you jump from sockets on the host to external 
ports on the NAT. I don't see how you reach this conclusion.

> Back to NAT port overloading. A collision occurs when 2 sessions share the
> same 5-tuple.

Stop right here. Some NATs don't track sessions. Those NATs don't care 
about 5-tuples. All they do is map internal 3-tuple to external 3-tuple. 
So for those NATs there is no conflict. They will just translate the 
packets according to the existing mapping.

All the following doesn't make sense to me given this.


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

DTN made easy, lean, and smart -->
NAT64/DNS64 open-source        -->
STUN/TURN server               -->