Re: [BEHAVE] (no subject)

ivan c <ivan@cacaoweb.org> Thu, 27 June 2013 14:16 UTC

Return-Path: <ivan@cacaoweb.org>
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 EBF5521F88AC for <behave@ietfa.amsl.com>; Thu, 27 Jun 2013 07:16:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.382
X-Spam-Level:
X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599]
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 HyY4Zz+8x+xB for <behave@ietfa.amsl.com>; Thu, 27 Jun 2013 07:16:21 -0700 (PDT)
Received: from mail.cacaoweb.org (mail.cacaoweb.org [46.105.102.78]) by ietfa.amsl.com (Postfix) with ESMTP id AD71B21F88A9 for <behave@ietf.org>; Thu, 27 Jun 2013 07:16:21 -0700 (PDT)
Received: from www-data by mail.cacaoweb.org with local (Exim 4.72) (envelope-from <ivan@cacaoweb.org>) id 1UsD0j-0007Z8-4z; Thu, 27 Jun 2013 16:17:21 +0200
To: Simon Perreault <simon.perreault@viagenie.ca>
X-PHP-Originating-Script: 0:func.inc
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Date: Thu, 27 Jun 2013 16:17:21 +0200
From: ivan c <ivan@cacaoweb.org>
Organization: cacaoweb
In-Reply-To: <51CC4204.1040109@viagenie.ca>
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>
Message-ID: <ee99cf8f77c13e5bdada1884430020fb@cacaoweb.org>
X-Sender: ivan@cacaoweb.org
User-Agent: RoundCube Webmail/0.3.1
Cc: behave@ietf.org
Subject: Re: [BEHAVE] (no subject)
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ivan@cacaoweb.org
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:16:26 -0000

On Thu, 27 Jun 2013 15:45:40 +0200, Simon Perreault
<simon.perreault@viagenie.ca> wrote:
> 
> So what is the problem exactly?
> 

I have no problem, however it seems that you do have an attitude problem
:)
(joking, but please do try keep it in friendly way, as this is a public
mailing list after all)


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


> The functionality is available on many (all?) platforms, and 
> applications use it.

Which applications use it for TCP? Reference needed.
(Although I fully agree that p2p applications should consider using it)
This was the point of this post:
http://www.ietf.org/mail-archive/web/behave/current/msg10884.html
With this follow-up:
http://www.ietf.org/mail-archive/web/behave/current/msg10906.html


>> I also made the point in numerous posts already that SO_REUSEADDR is
used
>> to bypass the TIME_WAIT state on closed sockets, and even this is not
>> specified by POSIX. See
>> http://www.ietf.org/mail-archive/web/behave/current/msg10876.html
>> In another post, I explained that if you use SO_REUSEADDR on all your
TCP
>> sockets you expose them to the old duplicate problem, and the worst is
>> that
>> this crosses applications boundaries. See
>> http://www.ietf.org/mail-archive/web/behave/current/msg10906.html
> 
> We're talking about UDP here. There is no TIME_WAIT.
> 

No, we are talking about TCP and UDP, this is the point of the whole
discussion.
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.



-- 
_Ivan Chollet_