Subject: [pcp] Requesting adoption of draft-boucadair-pcp-rtp-rtcp

From: <[email-masked]>
Date: Thu, 19 Apr 2012 09:41:27 +0200

Dear all,
 
Senthil and myself are requesting the WG to consider adopting this document as a WG item.

The document specifies a simple solution for a well-defined problem. More details are in the draft.

	Title           : Reserving N and N+1 Ports with PCP
	Filename        : draft-boucadair-pcp-rtp-rtcp-04.txt
	Pages           : 14
	Date            : 2012-04-19

   This document defines a new PCP Option to reserve a pair of ports (N
   and N+1) by a PCP-controlled device while preserving the parity and
   contiguity.  This PCP Option eases the NAT traversal for applications
   having requirements on the port parity and contiguity (e.g., RTP/
   RTCP). 

   http://tools.ietf.org/html/draft-boucadair-pcp-rtp-rtcp-04

Cheers,
Med

---

From: Simon Perreault <[email-masked]>
Date: Thu, 19 Apr 2012 09:06:16 -0400

> Senthil and myself are requesting the WG to consider adopting this document as a WG item.

I think this should be adopted. This PCP extension is very simple and 
constrained to a particular use case, which I like. It is also easy to 
implement because the semantics of other operations (keep-alive, delete) 
are not changed: the two mappings created by this option are treated 
exactly like independent mappings from the moment they are created.

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

---

From: Xiaohong Deng <[email-masked]>
Date: Fri, 20 Apr 2012 16:12:54 +0800

On Thu, Apr 19, 2012 at 9:06 PM, Simon Perreault
<[email-masked]> wrote:
> implement because the semantics of other operations (keep-alive, delete) are
> not changed: the two mappings created by this option are treated exactly
> like independent mappings from the moment they are created.
>
> Simon
> --
> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp

+1 for support of the adaption. The driven of this I-D came from
addressing back compatibility of current practices, e.g., RTP/RTCP,
and it's easy implementable. Also importantly as Simon has pointed out
that it's compliant with basic design as PCP base document.

-- 
-Xiaohong

Open source mB4 for Multicast DS-Lite: http://sourceforge.net/projects/mb4/
Open source PCP: http://sourceforge.net/projects/pcpclient/
Open source A+P: http://opensourceaplusp.weebly.com/

---

From: Maglione Roberta <[email-masked]>
Date: Mon, 23 Apr 2012 10:47:09 +0200

Hello,
   I have a clarification question:
What's the difference between this draft and draft-tsou-pcp-natcoord?
My understanding is that draft-boucadair-pcp-rtp-rtcp defines a new PCP Option to reserve a pair of ports (N and N+1) while Tina's draft proposes a new option to reserve a more generic "set of ports".

Isn't N and N+1 range just a special case of a generic "set of port"?

Thanks,
Roberta

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: giovedì 19 aprile 2012 9.41
To: [email-masked]
Subject: [pcp] Requesting adoption of draft-boucadair-pcp-rtp-rtcp

Dear all,

Cheers,
Med

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

---

From: <[email-masked]>
Date: Mon, 23 Apr 2012 11:04:53 +0200

Dear Roberta,

The N/N+1 Option is designed with a focus on the RTP/RTCP case. As such, in addition to port contiguity there is also a requirement to preserve port parity (http://tools.ietf.org/html/draft-boucadair-pcp-rtp-rtcp-04#section-3.1). FWIW, below an excerpt from RFC4784:

4.2.2. Port Parity

   Some NATs preserve the parity of the UDP port, i.e., an even port
   will be mapped to an even port, and an odd port will be mapped to an
   odd port.  This behavior respects the [RFC3550] rule that RTP use
   even ports, and RTCP use odd ports.  RFC 3550 allows any port numbers
   to be used for RTP and RTCP if the two numbers are specified
   separately; for example, using [RFC3605].  However, some
   implementations do not include RFC 3605, and do not recognize when
   the peer has specified the RTCP port separately using RFC 3605.  If
   such an implementation receives an odd RTP port number from the peer
   (perhaps after having been translated by a NAT), and then follows the
   RFC 3550 rule to change the RTP port to the next lower even number,
   this would obviously result in the loss of RTP.  NAT-friendly
   application aspects are outside the scope of this document.  It is
   expected that this issue will fade away with time, as implementations
   improve.  Preserving the port parity allows for supporting
   communication with peers that do not support explicit specification
   of both RTP and RTCP port numbers.

   REQ-4:  It is RECOMMENDED that a NAT have a "Port parity
      preservation" behavior of "Yes".

   Justification:  This is to avoid breaking peer-to-peer applications
      that do not explicitly and separately specify RTP and RTCP port
      numbers and that follow the RFC 3550 rule to decrement an odd RTP
      port to make it even.  The same considerations apply, as per the
      IP address pooling requirement.

N/N+1 Option makes use of an existing PCP OpCode with minor change at the PCP Server during the creation of the two mappings. Once the 2 mappings are created, they are handled as any individual mapping created using MAP.

draft-tsou-* targets another use case which is to delegate a set of port to a requesting device: draft-tsou-* does offload the NAT to the requesting PCP Client while in the N/N+1 case the NAT is enforced in the PCP-controlled device itself.

I hope this clarifies your concern.

Cheers,
Med 

>-----Message d'origine-----
>De : Maglione Roberta [mailto:[email-masked]] 
>Envoyé : lundi 23 avril 2012 10:47
>À : BOUCADAIR Mohamed OLNC/NAD/TIP; [email-masked]; Tina TSOU
>Objet : RE: Requesting adoption of draft-boucadair-pcp-rtp-rtcp
>
>Hello,
>My understanding is that draft-boucadair-pcp-rtp-rtcp defines 
>a new PCP Option to reserve a pair of ports (N and N+1) while 
>Tina's draft proposes a new option to reserve a more generic 
>"set of ports".
>
>Questo messaggio e i suoi allegati sono indirizzati 
>esclusivamente alle persone indicate. La diffusione, copia o 
>qualsiasi altra azione derivante dalla conoscenza di queste 
>informazioni sono rigorosamente vietate. Qualora abbiate 
>ricevuto questo documento per errore siete cortesemente 
>pregati di darne immediata comunicazione al mittente e di 
>provvedere alla sua distruzione, Grazie.
>
>This e-mail and any attachments is confidential and may 
>contain privileged information intended for the addressee(s) 
>only. Dissemination, copying, printing or use by anybody else 
>is unauthorised. If you are not the intended recipient, please 
>delete this message and any attachments and advise the sender 
>by return e-mail, Thanks.
>
>