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_
- Re: [BEHAVE] (no subject) Senthil Sivakumar (ssenthil)
- Re: [BEHAVE] (no subject) Dan Wing
- [BEHAVE] REQ 1 and REQ 7 of RFC5382 were supposed… ivan c
- Re: [BEHAVE] REQ 1 and REQ 7 of RFC5382 were supp… Simon Perreault
- Re: [BEHAVE] REQ 1 and REQ 7 of RFC5382 were supp… ivan c
- Re: [BEHAVE] REQ 1 and REQ 7 of RFC5382 were supp… Simon Perreault
- Re: [BEHAVE] REQ 1 and REQ 7 of RFC5382 were supp… Senthil Sivakumar (ssenthil)
- Re: [BEHAVE] REQ 1 and REQ 7 of RFC5382 were supp… ivan c
- Re: [BEHAVE] (no subject) ivan c
- Re: [BEHAVE] (no subject) Senthil Sivakumar (ssenthil)
- Re: [BEHAVE] (no subject) ivan c
- Re: [BEHAVE] (no subject) Rajiv Asati (rajiva)
- Re: [BEHAVE] (no subject) ivan c
- Re: [BEHAVE] (no subject) Simon Perreault
- Re: [BEHAVE] (no subject) Dan Wing
- Re: [BEHAVE] (no subject) ivan c
- Re: [BEHAVE] TCP port overloading, preservation a… ivan c
- Re: [BEHAVE] (no subject) ivan c
- Re: [BEHAVE] (no subject) Simon Perreault
- Re: [BEHAVE] TCP port overloading, preservation a… Simon Perreault
- Re: [BEHAVE] (no subject) ivan c
- Re: [BEHAVE] (no subject) ivan c
- Re: [BEHAVE] TCP port overloading, preservation a… ivan c
- Re: [BEHAVE] (no subject) Simon Perreault
- Re: [BEHAVE] TCP port overloading, preservation a… Simon Perreault
- Re: [BEHAVE] (no subject) ivan c
- Re: [BEHAVE] (no subject) cb.list6
- Re: [BEHAVE] (no subject) Simon Perreault
- Re: [BEHAVE] (no subject) Simon Perreault
- Re: [BEHAVE] (no subject) Reinaldo Penno (repenno)
- Re: [BEHAVE] (no subject) ivan c
- Re: [BEHAVE] (no subject) Simon Perreault
- Re: [BEHAVE] (no subject) ivan c
- Re: [BEHAVE] (no subject) ivan c
- Re: [BEHAVE] (no subject) Simon Perreault
- Re: [BEHAVE] (no subject) Simon Perreault
- Re: [BEHAVE] (no subject) Mark Andrews
- Re: [BEHAVE] (no subject) ivan c
- [BEHAVE] DNS vs port overloading Simon Perreault
- Re: [BEHAVE] (no subject) ietfdbh
- Re: [BEHAVE] (no subject) Simon Perreault
- Re: [BEHAVE] DNS vs port overloading Mark Andrews
- Re: [BEHAVE] DNS vs port overloading Simon Perreault
- Re: [BEHAVE] (no subject) ivan c
- Re: [BEHAVE] (no subject) Simon Perreault
- Re: [BEHAVE] (no subject) ivan c
- Re: [BEHAVE] (no subject) Tom Taylor
- Re: [BEHAVE] (no subject) Simon Perreault
- Re: [BEHAVE] (no subject) ivan c
- Re: [BEHAVE] (no subject) ivan c
- Re: [BEHAVE] DNS vs port overloading Mark Andrews
- Re: [BEHAVE] (no subject) ivan c
- Re: [BEHAVE] (no subject) Simon Perreault
- Re: [BEHAVE] DNS vs port overloading Simon Perreault
- [BEHAVE] UDP socket programming Simon Perreault
- Re: [BEHAVE] TCP port overloading, preservation a… ivan c
- Re: [BEHAVE] DNS vs port overloading ivan c