Re: [BEHAVE] (no subject)

Simon Perreault <simon.perreault@viagenie.ca> Thu, 27 June 2013 14:29 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 32E7B21F9DE3 for <behave@ietfa.amsl.com>; Thu, 27 Jun 2013 07:29:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.218
X-Spam-Level:
X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[AWL=0.382, 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 MEm+ls4jsYTA for <behave@ietfa.amsl.com>; Thu, 27 Jun 2013 07:29:32 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2C521F9DEB for <behave@ietf.org>; Thu, 27 Jun 2013 07:29:14 -0700 (PDT)
Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:7ddf:d947:bc5f:fe38]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 6D81A47121; Thu, 27 Jun 2013 10:29:09 -0400 (EDT)
Message-ID: <51CC4C37.90708@viagenie.ca>
Date: Thu, 27 Jun 2013 16:29:11 +0200
From: Simon Perreault <simon.perreault@viagenie.ca>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
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> <51CC4204.1040109@viagenie.ca> <ee99cf8f77c13e5bdada1884430020fb@cacaoweb.org>
In-Reply-To: <ee99cf8f77c13e5bdada1884430020fb@cacaoweb.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: 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: Thu, 27 Jun 2013 14:29:33 -0000

Le 2013-06-27 16:17, ivan c a écrit :
>> My point is that UDP and TCP are not different from the point of view of
>> the NAT w.r.t. port preservation, since applications routinely call
>> connect() on UDP sockets and it is entirely possible that two UDP
>> sockets share the same local endpoint. POSIX standards have nothing to
>> do with it.
>
> It has everything to do with POSIX standards. Options that are outside the
> POSIX standards are usually quite flaky. See the shortcomings of the
> SO_REUSEADDR option that I mention in my previous post.
> I also totally agree that: UDP and TCP are not different from the point of
> view of the NAT w.r.t. port overloading (i assume you meant port
> overloading, you wrote "port preservation")

No, I meant port preservation. I'm having a hard time following, and I 
thought that the UDP-vs-TCP distinction was w.r.t. port preservation.

> It's just that applications usually use many more TCP local endpoints than
> UDP ones. See bittorrent and all others, empirical observations. So if
> there is a shortage of internal endpoints, it's more likely to happen for
> TCP. But it can also happen for UDP, i totally agree.

Fully agree.

>> The functionality is available on many (all?) platforms, and
>> applications use it.
>
> Which applications use it for TCP? Reference needed.

By "it", I was referring to "the ability to open multiple sockets bound 
to the same client endpoint". With TCP, applications do it by default.

> SO_REUSEADDR is not needed on UDP anyway since you can already multiplex
> multiple sessions over the same UDP socket. Applications can still use it
> for pure convenience though, i agree, your previous post being a nice
> illustration of this use case.

Exactly. My point is that UDP applications do sometimes create 5-tuples 
sharing the same local 3-tuple. Empirically we see that it is a minority 
of the traffic, but the functionality is there, is being used, and needs 
to be considered in the recommendations for NAT that we end up writing.

Simon