Re: [pcp] Stephen Farrell's No Objection on draft-ietf-pcp-port-set-12: (with COMMENT)

<mohamed.boucadair@orange.com> Thu, 22 October 2015 13:01 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1DFC1A21AA; Thu, 22 Oct 2015 06:01:04 -0700 (PDT)
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=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eIAMADlJsgKw; Thu, 22 Oct 2015 06:01:03 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E23B1A21A7; Thu, 22 Oct 2015 06:01:02 -0700 (PDT)
Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 6C1FE264420; Thu, 22 Oct 2015 15:01:00 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.27]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 3DD7335C045; Thu, 22 Oct 2015 15:01:00 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7C.corporate.adroot.infra.ftgroup ([fe80::8007:17b:c3b4:d68b%19]) with mapi id 14.03.0248.002; Thu, 22 Oct 2015 15:01:00 +0200
From: <mohamed.boucadair@orange.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, The IESG <iesg@ietf.org>
Thread-Topic: Stephen Farrell's No Objection on draft-ietf-pcp-port-set-12: (with COMMENT)
Thread-Index: AQHRDMca8DKO5rybrkyKzpbVLb+dbp53dREw
Date: Thu, 22 Oct 2015 13:00:59 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933008C84DF3@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <20151022121707.19305.9899.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B933008C84D92@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <5628D9B2.4090700@cs.tcd.ie>
In-Reply-To: <5628D9B2.4090700@cs.tcd.ie>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.5]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.10.16.122716
Archived-At: <http://mailarchive.ietf.org/arch/msg/pcp/ETQcO_P2B8KMGa4cvW3X3x7ZYFo>
Cc: "draft-ietf-pcp-port-set@ietf.org" <draft-ietf-pcp-port-set@ietf.org>, "pcp@ietf.org" <pcp@ietf.org>, "rapenno@yahoo.com" <rapenno@yahoo.com>, "pcp-chairs@ietf.org" <pcp-chairs@ietf.org>
Subject: Re: [pcp] Stephen Farrell's No Objection on draft-ietf-pcp-port-set-12: (with COMMENT)
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 22 Oct 2015 13:01:05 -0000

Re-,

You are right. This ** may ** be  inefficient....like it is also inefficient that a PCP server assigns a port of 20 ports while the clients asked only for 2. This is really a matter of policy to be configured to the PCP server. 

For example, a SIP UA that asks for 4 ports (2 for audio, and 2 for video) but gets only 3 from the server, may reissue another request to get two contiguous ports with parity preservation from the server. 
* If the port quota is not exceeded, the server will return two ports (this means one port won't be used). 
* If the port quota is exceeded, no port will be returned. In such case, the third port can be used for media stream (but the companion RTCP ports won't be available). 

Cheers,
Med

> -----Message d'origine-----
> De : Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]
> Envoyé : jeudi 22 octobre 2015 14:42
> À : BOUCADAIR Mohamed IMT/OLN; The IESG
> Cc : draft-ietf-pcp-port-set@ietf.org; pcp@ietf.org; rapenno@yahoo.com;
> pcp-chairs@ietf.org
> Objet : Re: Stephen Farrell's No Objection on draft-ietf-pcp-port-set-12:
> (with COMMENT)
> 
> 
> Hiya,
> 
> (The rest is fine, I've just a question on this)
> 
> On 22/10/15 13:39, mohamed.boucadair@orange.com wrote:
> > [Med] The decision about what to return to the server depends on the
> > policies configured to the server and the ports usage of a client. A
> > server that supports port parity and port set assignment will honor a
> > request as far as the port quota is not exceeded. I don't see a valid
> > argument to require the server to always return an even number of
> > ports if parity is requested.
> 
> Maybe I'm understanding it wrong, but if one of the reasons to
> set the parity bit in the request is that the client will only
> find an even set of ports useful then a server that returns an
> odd set of ports will be a tiny bit inefficient at least. It's
> not a big deal at all, but am I right in that?
> 
> S.