IETF Logo Mail Archive

Re: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09

Simon Perreault <simon.perreault@viagenie.ca> Mon, 07 January 2013 17:04 UTC

Return-Path: <simon.perreault@viagenie.ca>
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F26AD21F88D8 for <pcp@ietfa.amsl.com>; Mon, 7 Jan 2013 09:04:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FDWhCrTplykO for <pcp@ietfa.amsl.com>; Mon, 7 Jan 2013 09:04:32 -0800 (PST)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5A91521F88CA for <pcp@ietf.org>; Mon, 7 Jan 2013 09:04:32 -0800 (PST)
Received: from porto.nomis80.org (85-169-40-152.rev.numericable.fr [85.169.40.152]) by jazz.viagenie.ca (Postfix) with ESMTPSA id AC2B24039E; Mon, 7 Jan 2013 12:04:31 -0500 (EST)
Message-ID: <50EB001E.3030003@viagenie.ca>
Date: Mon, 07 Jan 2013 18:04:30 +0100
From: Simon Perreault <simon.perreault@viagenie.ca>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Dan Wing <dwing@cisco.com>
References: <45A697A8FFD7CF48BCF2BE7E106F06041E9D48@xmb-rcd-x04.cisco.com> <82256834F867D44BBB8E49E40D5448BB065955DC@BL2PRD0510MB386.namprd05.prod.outlook.com> <50EA9BF9.2010302@viagenie.ca> <023601cdecf7$fd33cc80$f79b6580$@cisco.com>
In-Reply-To: <023601cdecf7$fd33cc80$f79b6580$@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: pcp@ietf.org
Subject: Re: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Jan 2013 17:04:33 -0000

Le 2013-01-07 17:56, Dan Wing a écrit :
>> Another reason is to get a contiguous chunk. There is no guarantee that
>> multiple MAP requests will be able to obtain a contiguous chunk of port
>> numbers. Some applications may find this property necessary (e.g. SIP
>> clients).
>
> By SIP, do you mean RTP?  If so, it seems draft-boucadair-pcp-rtp-rtcp
> provides that functionality.  draft-tsou-pcp-natcoord could, too, if
> the size of the port-set is two ports, I guess?  Which should a client
> or a server use?

Right, but I was thinking about a slightly different use case than 
draft-boucadair: some applications just like to get ownership of a chunk 
of ports when they start. This is mostly an implementation artifact, not 
really a protocol constraint. I had SIP apps in mind, but I guess the 
same could be said of BitTorrent apps or other apps that eat ports.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

v2.23.0 | Report a Bug | By Email